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. 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]