Network work group Hongmiao Xia
Internet Draft Jianhua Gao
Intended status: Informational Fatai Zhang
Expires: April 2009 Huawei Technologies Co.,Ltd
October 24, 2008
Call Parameter Negotiation with GMPLS Calls
draft-xia-ccamp-gmpls-call-application-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 24, 2009.
Abstract
This document defines the use of Generalized Multi-Protocol Label
Switching (GMPLS) Calls for parameter negotiation in Automatically
Switched Optical Networks (ASON) and Wavelength Switched Optical
Networks (WSON). The intention of the document is to provide a
reference for the authors of future documents to understand the
application of GMPLS Calls.
<Lastname> Expires April 24, 2009 [Page 1]
Internet-Draft Parameter negotiation October 2008
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents
1. Introduction.................................................2
2. Problem Statement............................................3
2.1. Connection-Adaptation Negotiation for Ethernet Service..3
2.2. Service Parameter Negotiation in WSON...................4
3. Process of negotiation.......................................5
4. Example of required information for negotiation..............6
4.1. CONNECTION_ADAPTER information..........................6
4.1.1. FRAMING Sub-object.................................6
4.1.2. VCAT Sub-object....................................7
4.2. SERVICE_ATTRIBUTE information...........................7
4.2.1. CODE Sub-object....................................8
4.2.2. FEC Sub-object.....................................9
5. Security Considerations......................................9
6. Manageability Considerations................................10
7. IANA Considerations.........................................10
8. References..................................................10
9. Authors' Addresses..........................................11
Intellectual Property Statement................................11
Disclaimer of Validity.........................................12
Full Copyright Statement.......................................12
Acknowledgment.................................................12
1. Introduction
The concept of a Generalized Multi-Protocol Label Switching (GMPLS)
Call is introduced in [RFC 4974]. A Call is an agreement between
endpoints possibly in cooperation with the nodes that provide access
to the network. It is used to facilitate and manage a set of
Connections (that is, Label Switching Paths - LSPs) that provide end-
to-end data services. It may be established and maintained
independently of the Connections that it supports. Call setup may
include capability exchange, policy, authorization, and security.
This document defines the use of Call for parameter negotiation with
specific reference to its use in Automatically Switched Optical
Networks (ASON) and Wavelength Switched Optical Networks (WSON). The
Xia Expires April 24, 2009 [Page 2]
Internet-Draft Parameter negotiation October 2008
intention of the document is to provide a reference for the authors
of future documents to understand the application of GMPLS Calls.
2. Problem Statement
A Call is an agreement between endpoints possibly in cooperation with
the nodes that provide access to the network. Call setup may include
capability exchange, policy, authorization, and security. In this
document, we will describe the use of GMPLS Call in parameter
negotiation.
In some scenarios, service attributes have an effect on connection
setup. Because equipment from different vendors may have different
capabilities, a connection SHOULD only transit the nodes that all
support the attributes required by a connection. IGP extension could
solve this problem by advertising the attributes and capabilities of
all network nodes, but this would increase the burden on the control
plane. It is a good choice to introduce the function of parameter
negotiation into GMPLS Calls to deal with this kind of problem. In
the following subsection, two scenarios are presented.
2.1. Connection-Adaptation Negotiation for Ethernet Service
For Ethernet services over a transport network there is a key step to
adapt Ethernet frames into transport channels. This must be done
between the server edge nodes. The adaptation policy between ingress
and egress edge nodes must be consistent. These adaptation policies
include:
1) Encapsulation protocol at the edge node. This is responsible for
packet encapsulation, framing and rate adaptation. Examples
include GFP (Generic Framing Procedure), LAPS (Link Access
Procedure for SDH), HDLC (High Level Data Link Control protocol),
etc.
2) Connection type and connection number used by the edge node.
There are standard Contiguous Concatenation and Virtual
Concatenation (VCAT) schemes in SDH networks. The maximum
connection number of concatenation is different for different
devices and different signals when VCAT is used. So it is
necessary to negotiate the parameters of VCAT. This is described
in [VCAT-LCAS].
3) Flow control. When traffic increases in a burst, flow control can
be enabled. The ingress edge node can negotiate with the egress
edge node whether to start flow control in this case, and how to
apply the necessary control.
Xia Expires April 24, 2009 [Page 3]
Internet-Draft Parameter negotiation October 2008
All of these adaptation policies can be configured through the
Management Plane. However, in the case of a large number of services,
it is hard to perform fault localization when a configuration error
has occurred. So it is more flexible to introduce dynamic parameter
negotiation into this service. [RFC 4974] allows the Call and
Connection to be isolated so that the Connection can be established
with the correct connection-adaptation parameters according to the
result of parameter negotiation on the Call.
For example, see the following figure, Figure 1. R1 and R2 are client
nodes connected to the ASON via Ethernet interfaces. N1 and N6 are
service access points. When R1 sends a Call request to N1 for
Ethernet service, N1 includes the local capabilities for connection-
adaptation to the Call as request parameters. For example, supporting
GFP/LAPS, supporting VC-4-xc (x=1/4/16), supporting VCAT/LCAS,
supporting VC-4-xv(x=1-7) and the relevant connecting address. When
N6 receives the Call containing the connection-adaptation parameters,
it checks local capabilities and applies local policies. In the Call
response message, N6 will put the mapped capability as connection-
adaptation parameters. If no mapped capability can be found, then N6
will reject the Call and return corresponding reason.
+----+ +----+
+-| N2 |---| N3 |-+
/ +----+ +----+ \
/ \
+----+ +----+ +----+ +----+
| R1 |--| N1 | | N6 |--| R2 |
+----+ +----+ +----+ +----+
\ /
\ +----+ +----+ /
+-| N4 |---| N5 |-+
+----+ +----+
Figure 1: A Simple ASON Network
2.2. Service Parameter Negotiation in WSON
OTU is an important technology used to perform standard lambda
conversion in WDM systems. It exists in OTM and REG.
Coded Modulation is a key technique in long distance and high speed
Optical Transmission Systems. As different codes have distinct
Xia Expires April 24, 2009 [Page 4]
Internet-Draft Parameter negotiation October 2008
capabilities against noise, dispersion and non-linear distortion, the
maximum transmission distance will be extended without redundant
devices if an appropriate code is selected. Currently, OOK (On-Off
Keying Modulation), PSK (Phase Shift Keying Modulation) and PoISK
(Polarization-shift keying Modulation) are the most common modulation
techniques. In the establishment of a light path, it is necessary to
ensure that the Coded Modulation is consistent at each OTU.
FEC is a technique to improve the system performance and reduce the
cost of the system and extend the transmission distance by adding
redundant error-correcting code to transmission code-sequence and
thus reduce the SNR (Signal Noise Ratio) demand at receiver. In-band
FEC and simple out-band FEC are used in general WDM systems. In ULH
(Ultra-Long Haul) system, EFEC (Enhanced FEC) and SuperFEC are used
to achieve higher coding-gain. OTU with different FECs can not
understand each other. In-band FEC and simple out-band FEC have now
been standardized. Vendors MAY have different code in EFEC and
SuperFEC. Only the same code used in OTU can the service be
established.
For the reasons stated above, it is necessary to verify and negotiate
the attributes of Coded Modulation, FEC mode and code. Otherwise a
connection can be established with enough resource, but be unable to
bear service.
Some of these service attributes in OTU can be modified by
configuration. For example, the port can be configured to disable FEC,
or enable standard FEC, or EFEC. Generally, the light path is
computed by the control plane in WSON, and it is not suitable to do
the configuration manually. So it is necessary to add a key step
during path establishment in WSON to negotiate and configure the
service attributes.
3. Process of negotiation
The process for Call parameter negotiation SHOULD comply with the
Call procedures which are described in [RFC4974]. The node that
initiates the call puts the parameters that need to be negotiated in
a CALL_Attributes object [MLN-EXT] in the Notify message that signals
the Call request. It also lists all parameters and corresponding
value that it supports.
Some parameters are negotiated between ingress and egress, while
others should be negotiated among all domain border nodes in the path.
Which kind of negotiation is selected is out of scope in the document.
Xia Expires April 24, 2009 [Page 5]
Internet-Draft Parameter negotiation October 2008
When a node receives a call request Notify message including a
CALL_Attributes object with a parameter that needs to be negotiated,
it checks whether any of the values listed are supported.
o If none of the values is supported, then the receiver MUST reject
the call and generate a Notify message in response.
o If only parts of the values are not supported, then the receiver
can accept the call and modify the parameter by deleting the
values not supported. The remaining values are returned in the
Notify message that accepts the call.
o If all the values are supported, then the parameters are not
modified and are returned in the Notify message that accepts the
call.
When the call setup is complete, the ingress node will receive the
parameters that are supported by all nodes that participate in call
setup. It can select the preferred values with which to setup the LSP.
4. Example of required information for negotiation
This section describes the required information for parameter
negotiation for the problem presented above.
4.1. CONNECTION_ADAPTER information
The CONNECTION_ADAPTER information, which is suggested to be a sub-
object of CALL_Attributes object, is introduced to support
negotiation for Ethernet connection and adaptation during Call setup.
It MAY be included in a Notify message used for Call setup. This
optional information includes the link-local preference of connection
and adaptation for Ethernet service. The Call-initiating node MAY add
this information to a Notify message presenting the transport
parameter. Receiving this message, the Call-terminating node checks
the CONNECTION_ADAPTER information and match with local policy then
return its choice also in the CONNECTION_ADAPTER information.
The contents of the CONNECTION_ADAPTER information is defined as a
series of variable-length data items called sub-objects. The sub-
object format is defined as follows:
4.1.1. FRAMING Sub-object
FRAMING Sub-object indicates the encapsulation protocol that the
Call-initiating node (or Call-terminating node) preferred.
Xia Expires April 24, 2009 [Page 6]
Internet-Draft Parameter negotiation October 2008
This Sub-object has the following format:
Type = TBD, Length = 4
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |L|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following flags are currently defined. All other values are
reserved.
G (GFP - 1bit): When this flag is set, it means that the node
supports GFP encapsulation.
L (LAPS - 1bit): When this flag is set, it means that the node
support LAPS encapsulation.
Other flags are reserved and MUST be set to zero.
4.1.2. VCAT Sub-object
The information related to VCAT is already defined in VCAT TLV object
in [VCAT-LCAS] and the VCAT TLV object included in the
CALL_Attributes object implies that the initiating node supports VCAT
capability.
4.2. SERVICE_ATTRIBUTE information
The SERVICE_ATTRIBUTE information, which is suggested to be a sub-
object of CALL_Attributes object, is introduced to support
negotiation for the service attributes of OTU during Call setup such
attributes include service type, Coded Modulation, FEC mode and code.
It MAY be included in a Notify message used for Call setup. This
optional information includes the preference attribute of local OTU.
Call-initiating node MAY add this information to a Notify message
presenting the transport parameter of the OTU on OTM. Receiving this
message, OTU on REG and OTM checks the SERVICE_ATTRIBUTE information
and match with local policy then modify the information according to
its choice. If the last OTU has matched service attribute, then
returned Call message presents the negotiated parameter. If one of
the OTU has some service attribute no matched, then return failed
message.
Xia Expires April 24, 2009 [Page 7]
Internet-Draft Parameter negotiation October 2008
The contents of the SERVICE_ATTRIBUTE information is defined as a
series of variable-length data items called sub-objects. The sub-
object format is defined as follows:
4.2.1. CODE Sub-object
This Sub-object has the following format:
Type = TBD, Length = 4
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OOK mode |N|R| PSK mode|E|Q|D| PoISK mode |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OOK mode (On-Off Keying): 8it. The following flags for OOK are
currently defined. All other values are reserved.
N - NRZ, Non Return to Zero Modulation
R - RZ, Return to Zero Modulation
PSK mode (Phase Shift Keying): 8it. The following flags for PSK are
currently defined. All other values are reserved.
E - 8-DPSK, Differential 8-level Phase Shift Keying Modulation
Q - DQPSK, Differential Quadrature Phase Shift Keying Modulation
D - DPSK, Differential Phase Shift Keying Modulation
PoISK mode (Polarization-shift keying Modulation): 8it. The following
flag for PoISK is currently defined. All other values are reserved.
D - DpolSK, Duobinary Polarization-shift keying
The code Sub-object is the Coded Modulation method that supported by
OTU. The head OTU node initiates a call and set all code it supported.
The following OTU node along the path check the code, if some code
can not be support, then the corresponding bit will be cleared in the
Sub-object. If no one bit is set, it means the call failed.
Xia Expires April 24, 2009 [Page 8]
Internet-Draft Parameter negotiation October 2008
4.2.2. FEC Sub-object
This Sub-object has the following format:
Type = TBD, Length = 8
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Standard |I|O| EFEC |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SuperFEC |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Standard (16 bits): The following flags are currently defined. All
other values are reserved.
I - In-band FEC supported
O - Out-band FEC supported
EFEC (16 bits): The following flag is currently defined. All other
values are reserved.
E - Extended FEC supported. Now there is one Extended FEC method.
SuperFEC (16 bits): The following flag is currently defined. All
other values are reserved.
S - Super FEC supported. Now there is one Super FEC method.
This Sub-object is the FEC method that supported by OTU. The head OTU
node initiates a call and set all FEC it supported and needed in the
connection. The following OTU node along the path check the FEC, if
some FEC can not be supported, then the corresponding bit will be
cleared in the Sub-object. If no one bit is set, it means the call
failed.
5. Security Considerations
This document describes some applications for GMPLS Calls whose
mechanisms are described in [RFC4974]. It just introduces some new
Sub-objects for CALL_Attributes object which is described in [MLN-EXT]
and it does not introduce any new signaling messages. So this
document does not introduce any additional security considerations.
Xia Expires April 24, 2009 [Page 9]
Internet-Draft Parameter negotiation October 2008
6. Manageability Considerations
TBD.
7. IANA Considerations
TBD.
8. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4974] D. Papadimitriou, A. Farrel, "Generalized MPLS (GMPLS)
RSVP-TE Signaling Extensions in Support of Calls ", RFC
4974, August 2007.
[VCAT-LCAS] G. Bernstein, D. Caviglia, R. Rabbat, H. van Helvoort, ''
Operating Virtual Concatenation (VCAT) and the Link
Capacity Adjustment Scheme (LCAS) with Generalized Multi-
Protocol Label Switching (GMPLS)'', draft-ietf-ccamp-gmpls-
vcat-lcas-05.txt, Work in Progress, July 2008.
[MLN-EXT] Dimitri Papadimitriou et al.,''Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for Multi-Layer
and Multi-Region Networks (MLN/MRN) Generalized Multi-
Protocol Label Switching (GMPLS) Protocol'', Work in
Progress, ''draft-ietf-ccamp-gmpls-mln-extensions-02.txt''
Xia Expires April 24, 2009 [Page 10]
Internet-Draft Parameter negotiation October 2008
9. Authors' Addresses
Hongmiao Xia
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28971048
Email: xiahongmiao@huawei.com
Jianhua Gao
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: gjhhit@huawei.com
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Xia Expires April 24, 2009 [Page 11]
Internet-Draft Parameter negotiation October 2008
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Xia Expires April 24, 2009 [Page 12]