[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]