Internet DRAFT - draft-xia-ccamp-gmpls-call-application

draft-xia-ccamp-gmpls-call-application



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]