Network Working Group                                             Z. Lin
Request for Comments: 3474                         New York City Transit
Category: Informational                                    D. Pendarakis
                                                                 Tellium
                                                              March 2003


                 Documentation of IANA assignments for
           Generalized MultiProtocol Label Switching (GMPLS)
     Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
                        Usage and Extensions for
             Automatically Switched Optical Network (ASON)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The Generalized MultiProtocol Label Switching (GMPLS) suite of
   protocol specifications has been defined to provide support for
   different technologies as well as different applications.  These
   include support for requesting TDM connections based on Synchronous
   Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as
   Optical Transport Networks (OTNs).

   This document concentrates on the signaling aspects of the GMPLS
   suite of protocols, specifically GMPLS signaling using Resource
   Reservation Protocol - Traffic Engineering (RSVP-TE).  It proposes
   additional extensions to these signaling protocols to support the
   capabilities of an ASON network.

   This document proposes appropriate extensions towards the resolution
   of additional requirements identified and communicated by the ITU-T
   Study Group 15 in support of ITU's ASON standardization effort.










Lin & Pendarakis             Informational                      [Page 1]

RFC 3474      GMPLS RSVP-TE Usage and Extensions for ASON     March 2003


Table of Contents

   1. Conventions used in this document...............................3
   2. Introduction....................................................3
   3. Support for Soft Permanent Connection...........................3
   4. Support for Call................................................4
       4.1 Call Identifier and Call Capability........................4
            4.1.1 Call Identifier.....................................4
            4.1.2 Call Capability.....................................7
       4.2 What Does Current GMPLS Provide............................7
       4.3 Support for Call and Connection............................7
            4.3.1 Processing Rules....................................8
            4.3.2 Modification to Path Message........................8
            4.3.3 Modification to Resv Message........................9
            4.3.4 Modification to PathTear Message....................9
            4.3.5 Modification to PathErr Message....................10
            4.3.6 Modification to Notify Message.....................10
   5.  Support For Behaviors during Control Plane Failures...........11
   6.  Support For Label Usage.......................................12
   7.  Support for UNI and E-NNI Signaling Session...................13
   8.  Additional Error Cases........................................14
   9.  Optional Extensions for Supporting
       Complete Separation of Call and Connection....................15
       9.1 Call Capability.........;.................................15
       9.2 Complete Separation of Call and
           Connection (RSVP-TE Extensions)...........................16
            9.2.1 Modification to Path...............................16
            9.2.2 Modification to Resv...............................17
            9.2.3 Modification to PathTear...........................18
            9.2.4 Modification to PathErr............................18
            9.2.5 Modification to Notify.............................18
   10. Security Considerations.......................................19
   11. IANA Considerations...........................................19
       11.1 Assignment of New Messages...............................19
       11.2 Assignment of New Objects and Sub-Objects................19
       11.3 Assignment of New C-Types................................20
       11.4 Assignment of New Error Code/Values......................20
   12. Acknowledgements..............................................20
   13. References....................................................21
       13.1 Normative References.....................................21
       13.2 Informative References...................................22
   14. Intellectual Property.........................................23
   15. Contributors Contact Information..............................24
   16. Authors' Addresses............................................24
   17. Full Copyright Statement......................................25






Lin & Pendarakis             Informational                      [Page 2]

RFC 3474      GMPLS RSVP-TE Usage and Extensions for ASON     March 2003


1. 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 BCP 14, RFC 2119
   [RFC2119].

2. Introduction

   This document contains the extensions to GMPLS for ASON-compliant
   networks [G7713.2].  The requirements describing the need for these
   extensions are provided in [GMPLS-ASON] as well as [ASON-RQTS].
   These include:

   -    Support for call and connection separation
   -    Support for soft permanent connection
   -    Support for extended restart capabilities
   -    Additional error codes/values to support these extensions

   This document concentrates on the signaling aspects of the GMPLS
   suite of protocols, specifically GMPLS signaling using RSVP-TE.  It
   introduces extensions to GMPLS RSVP-TE to support the capabilities as
   specified in the above referenced documents.  Specifically, this
   document uses the messages and objects defined by [RFC2205],
   [RFC2961], [RFC3209], [RFC3471], [RFC3473], [OIF-UNI1] and [RFC3476]
   as the basis for the GMPLS RSVP-TE protocol, with additional
   extensions defined in this document.

3. Support for Soft Permanent Connection

   In the scope of ASON, to support soft permanent connection (SPC) for
   RSVP-TE, one new sub-type for the GENERALIZED_UNI object is defined.
   The GENERALIZED_UNI object is defined in [RFC3476] and [OIF-UNI1].
   This new sub-type has the same format and structure as the
   EGRESS_LABEL (the sub-type is the suggested value for the new sub-
   object):

   -    SPC_LABEL (Type=4, Sub-type=2)

   The label association of the permanent ingress segment with the
   switched segment at the switched connection ingress node is a local
   policy matter (i.e., between the management system and the switched
   connection ingress node) and is thus beyond the scope of this
   document.







Lin & Pendarakis             Informational                      [Page 3]

RFC 3474      GMPLS RSVP-TE Usage and Extensions for ASON     March 2003


   The processing of the SPC_LABEL sub-object follows that of the
   EGRESS_LABEL sub-object [OIF-UNI1].  Note that although the explicit
   label control described in [RFC3471] and [RFC3473] may provide a
   mechanism to support specifying the egress label in the context of
   supporting the GMPLS application, the SPC services support for the
   ASON model uses the GENERALIZED_UNI object for this extension to help
   align the model for both switched connection and soft permanent
   connection, as well as to use the service level and diversity
   attributes of the GENERALIZED_UNI object.

4. Support for Call

   To support basic call capability (logical call/connection
   separation), a call identifier is introduced to the RSVP-TE message
   sets.  This basic call capability helps introduce the call model;
   however, additional extensions may be needed to fully support the
   canonical call model (complete call/connection separation).

4.1 Call Identifier and Call Capability

   A Call identifier object is used in logical call/connection
   separation while both the Call identifier object and a Call
   capability object are used in complete call/connection separation.

4.1.1 Call Identifier

   To identify a call, a new object is defined for RSVP-TE.  The CALL_ID
   object carries the call identifier.  The value is globally unique
   (the Class-num is the suggested value for the new object):

   CALL_ID (Class-num = 230)

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |Class-Num (230)|    C-Type     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Call identifier                        |
   ~                              ...                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Where the following C-types are defined:

   -  C-Type = 1 (operator specific): The call identifier contains an
      operator specific identifier.

   -  C-Type = 2 (globally unique): The call identifier contains a
      globally unique part plus an operator specific identifier.



Lin & Pendarakis             Informational                      [Page 4]

RFC 3474      GMPLS RSVP-TE Usage and Extensions for ASON     March 2003


   The following structures are defined for the call identifier:

   -  Call identifier: generic [Length*8-32]-bit identifier.  The number
      of bits for a call identifier must be multiples of 32 bits, with a
      minimum size of 32 bits.

   The structure for the globally unique call identifier (to guarantee
   global uniqueness) is to concatenate a globally unique fixed ID
   (composed of country code, carrier code, unique access point code)
   with an operator specific ID (where the operator specific ID is
   composed of a source LSR address and a local identifier).

   Therefore, a generic CALL_ID with global uniqueness includes  (composed of  plus  plus ) and  (composed of  plus ).  For a CALL_ID that only
   requires operator specific uniqueness, only the  is needed, while for a CALL_ID that is required to be globally
   unique, both  and  are needed.

   The  shall consist of a three-character International
   Segment (the ) and a twelve-character National Segment
   (the  plus ).  These
   characters shall be coded according to ITU-T Recommendation T.50. The
   International Segment (IS) field provides a 3 character ISO 3166
   Geographic/Political Country Code.  The country code shall be based
   on the three-character uppercase alphabetic ISO 3166 Country Code
   (e.g., USA, FRA).

   National Segment (NS):
      The National Segment (NS) field consists of two sub-fields:

      - the first subfield contains the ITU Carrier Code
      - the second subfield contains a Unique Access Point Code.

   The ITU Carrier Code is a code assigned to a network operator/service
   provider, maintained by the ITU-T Telecommunication Service Bureauin
   association with Recommendation M.1400.  This code consists of 1-6
   left-justified alphabetic, or leading alphabetic followed by numeric,
   characters (bytes).  If the code is less than 6 characters (bytes),
   it is padded with a trailing NULL to fill the subfield.

   The Unique Access Point Code is a matter for the organization to
   which the country code and ITU carrier code have been assigned,
   provided that uniqueness is guaranteed.  This code consists of 1-6
   characters (bytes), trailing NULL, completing the 12-character
   National Segment.  If the code is less than 6 characters, it is
   padded by a trailing NULL to fill the subfield.



Lin & Pendarakis             Informational                      [Page 5]

RFC 3474      GMPLS RSVP-TE Usage and Extensions for ASON     March 2003


   Format of the National Segment

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ITU carrier code                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ITU carrie dode (cont)        |  Unique access point code     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Unique access point code (continued)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the Call identifier field for C-Type = 1:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |Class-Num (230)|  C-Type  (1)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |                     Resv                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Source LSR address                       |
   ~                              ...                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Local identifier  (continued)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+























Lin & Pendarakis             Informational                      [Page 6]

RFC 3474      GMPLS RSVP-TE Usage and Extensions for ASON     March 2003


   The format of the Call identifier field for C-Type = 2:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |Class-Num (230)|  C-Type  (2)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |               IS (3 bytes)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         NS (12 bytes)                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Source LSR address                       |
   ~                              ...                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Local identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Local identifier  (continued)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In both cases, a "Type" field is defined to indicate the type of
   format used for the source LSR address.  The Type field has the
   following meaning:
      For Type=0x01, the source LSR address is 4 bytes
      For Type=0x02, the source LSR address is 16 bytes
      For Type=0x03, the source LSR address is 20 bytes
      For type=0x04, the source LSR address is 6 bytes
      For type=0x7f, the source LSR address has the length defined by
          the vendor

      Source LSR address:
            An address of the LSR controlled by the source network.

      Local identifier:
            A 64-bit identifier that remains constant over the life of
            the call.

   Note that if the source LSR address is assigned from an address space
   that is globally unique, then the operator-specific CALL_ID may also
   be used to represent a globally unique CALL_ID.  However, this is not
   guaranteed since the source LSR address may be assigned from an
   operator-specific address space.








Lin & Pendarakis             Informational                      [Page 7]

RFC 3474      GMPLS RSVP-TE Usage and Extensions for ASON     March 2003


4.1.2 Call Capability

   The call capability feature is provided in Section 10.  This is an
   optional capability.  If supported, section 10 extensions must be
   followed.

4.2 What Does Current GMPLS Provide

   The signaling mechanism defined in [RFC2961], [RFC3209] and [RFC3471]
   supports automatic connection management; however it does not provide
   capability to support the call model.  A call may be viewed as a
   special purpose connection that requires a different subset of
   information to be carried by the messages.  This information is
   targeted to the call controller for the purpose of setting up a
   call/connection association.

4.3 Support for Call and Connection

   Within the context of this document, every call (during steady state)
   may have one (or more) associated connections.  A zero connection
   call is defined as a transient state, e.g., during a break-before-
   make restoration event.

   In the scope of ASON, to support a logical call/connection
   separation, a new call identifier is needed as described above.  The
   new GENERALIZED_UNI object is carried by the Path message.  The new
   CALL_ID object is carried by the Path, Resv, PathTear, PathErr, and
   Notify messages.  The ResvConf message is left unmodified.  The
   CALL_ID object (along with other objects associated with a call,
   e.g., GENERALIZED_UNI) is processed by the call controller, while
   other objects included in these messages are processed by the
   connection controller as described in [RFC3473].  Processing of the
   CALL_ID (and related) object is described in this document.

   Note: unmodified RSVP message formats are not listed below.

4.3.1 Processing Rules

   The following processing rules are applicable for call capability:

   -  For initial calls, the source user MUST set the CALL_ID's C-Type
      and call identifier value to all-zeros.
   -  For a new call request, the first network node sets the
      appropriate C-type and value for the CALL_ID.
   -  For an existing call (in case CALL_ID is non-zero) the first
      network node verifies existence of the call.





Lin & Pendarakis             Informational                      [Page 8]

RFC 3474      GMPLS RSVP-TE Usage and Extensions for ASON     March 2003


   -  The CALL_ID object on all messages MUST be sent from the ingress
      call controller to egress call controller by all other
      (intermediate) controllers without alteration.  Indeed, the
      Class-Num is chosen such that a node which does not support ASON
      extensions to GMPLS forwards the object unmodified (value in the
      range 11bbbbbb).
   -  The destination user/client receiving the request uses the CALL_ID
      value as a reference to the requested call between the source user
      and itself.  Subsequent actions related to the call uses the
      CALL_ID as the reference identifier.

4.3.2 Modification to Path Message

    ::=    
        [  ]
        [ [ |
                ] ... ]
        [  ]
        
        
        
        [  ]
        
        [  ]
        [  ]
        [  ... ]
        [  ]
        [  ]
        [  ]
        [  ]
        [  ... ]
        

   The format of the sender descriptor for unidirectional LSPs is not
   modified by this document.

   The format of the sender descriptor for bidirectional LSPs is not
   modified by this document.

   Note that although the GENERALIZED_UNI and CALL_ID objects are
   optional for GMPLS signaling, these objects are mandatory for ASON-
   compliant networks, i.e., the Path message MUST include both
   GENERALIZED_UNI and CALL_ID objects.








Lin & Pendarakis             Informational                      [Page 9]

RFC 3474      GMPLS RSVP-TE Usage and Extensions for ASON     March 2003


4.3.3 Modification to Resv Message

    ::=       
        [  ]
        [ [ |
                ] ... ]
        [  ]
        
        
        
        [  ]
        [  ]
        
        [  ]
        [  ]
        [  ... ]