CCAMP Working Group                                    D. Papadimitriou
Internet Draft                                                  Alcatel
Document: draft-lin-ccamp-gmpls-ason-rsvpte-01.txt 
                                                                 Z. Lin
                                                                 Lucent

                                                          D. Pendarakis
                                                                Tellium
 
Expiration Date: February 2003                              August 2002
 
 
         Generalized MPLS (GMPLS) RSVP-TE Usage and Extensions  
           For Automatically Switched Optical Network (ASON) 
 
 
Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1].  
    
   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. 
    
    
1. Abstract 
    
   The 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 SDH/SONET as well as Optical Transport Networks (OTNs).  
    
   This document concentrates on the signaling aspects of the GMPLS 
   suite of protocols, specifically GMPLS signaling using RSVP-TE. It 
   proposes additional extensions to these signaling protocols to 
   support the capabilities of an ASON network. 
    

  
Lin                                                                  1 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
   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. 
    
    
2. 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 [2]. 
    
    
3. Introduction 
    
   This document contains the extensions to GMPLS to support the ASON 
   capabilities. 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 assumes the messages and objects defined by [RFC2205], 
   [RFC2961], [RFC3209], [GMPLS-SIG], [GMPLS-RSVPTE], and [OIF-UNI1] as 
   the basis for the protocols, with extensions in addition to those 
   already defined by these referenced documents.  
    
   Note that from the perspective of the ASON model ResvErr and ResvTear 
   messages are not used. For backwards compatibility, when an ASON-
   compliant GMPLS node receives either a ResvErr or ResvTear as a 
   response during the setup phase of message exchange, the GMPLS-ASON 
   node should instead issue a PathTear message downstream and a PathErr 
   (with Path_State_Removed flag set) message upstream. This is so that 
   RSVP states are immediately removed upon error during the setup 
   process. 
    
    
4. Support for Soft Permanent Connection 
    


  
Lin                                                                  2 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
   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 Annex A (and may also be 
   found in [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 [TBA]) 
    
   The label association of the ingress permanent segment with the 
   switched segment at the switched connection ingress node (i.e. link 
   #1 shown above) 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. 
    
   The processing of the SPC_LABEL sub-object follows that for the 
   EGRESS_LABEL sub-object [OIF-UNI1]. Note that although the explicit 
   label control described in [GMPLS-SIG] and [GMPLS-RSVPTE] 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. 
    
    
5. Support for Call 
    
5.1 Call Identifier and Call Capability 
    
   Call identifier is used in logical call/connection separation while 
   Call capability is used in complete call/connection separation. The 
   latter is described in the non-normative appendix I.  
    
    
5.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 = 227 [TBA]) 
    
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

  
Lin                                                                  3 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
   |            Length             |Class-Num (227)|    C-Type     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        Call identifier                        | 
   ~                              ...                              ~ 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
   Where the following C-types are defined: 
    
   -    C-Type = 1: The call identifier contains operator specific 
        identifier 
   -    C-Type = 2: The call identifier contains globally unique part 
        plus an operator specific identifier 
    
   The following structures are defined for the call identifier: 
    
   -    Call identifier: generic [Length*8-32]-bit identifier. The 
        number of bits for call identifier must be multiples of 32 bits, 
        with minimum size of 32 bits. 
    
   A possible structure and format of the CALL_ID is described in 
   [GMPLS-ASON].  
    
    
5.1.2 Call Capability 
    
   The call capability feature is provided in the appendix I.  
    
    
5.2 What Does Current GMPLS Provide 
    
   The signaling mechanism defined in [RFC2961], [RFC3209] and [GMPLS-
   SIG] 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. The subset of information required for a 
   call is currently for further study. 
    
    
5.3 Support for Call and Connection 
    
   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; 

  
Lin                                                                  4 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
   however, additional extensions may be needed to fully support the 
   canonical call model (complete call/connection separation). 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 message. 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 [GMPLS-RSVPTE]. Processing of the CALL_ID 
   (and related) object is described in this document. 
    
   Note: unmodified RSVP message formats are not listed below. 
    
    
5.3.1 Processing Rules 
    
   The following processing rules are applicable for the call 
   capability: 
    
   -    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. 
   -    Subsequent receiving network nodes (in particular the border 
        nodes) and the destination node MAY process (i.e. verify) the 
        CALL_ID object. 
   -    The CALL_ID object on all messages MUST be copied unmodified 
        from the ingress message to the egress message by all other 
        (intermediate) nodes. 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 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. 
    
    

  
Lin                                                                  5 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
5.3.2 Modification to Path Message 
    
   <Path Message> ::=    <Common Header> 
        [ <INTEGRITY> ] 
        [ [<MESSAGE_ID_ACK> |  
                <MESSAGE_ID_NACK>] ... ] 
        [ <MESSAGE_ID> ] 
        <SESSION> 
        <RSVP_HOP> 
        <TIME_VALUES> 
        [ <EXPLICIT_ROUTE> ] 
        <LABEL_REQUEST> 
        [ <CALL_ID> ] 
        [ <PROTECTION> ] 
        [ <LABEL_SET> ... ] 
        [ <SESSION_ATTRIBUTE> ] 
        [ <NOTIFY_REQUEST> ] 
        [ <ADMIN_STATUS> ] 
        [ <GENERALIZED_UNI> ] 
        [ <POLICY_DATA> ... ] 
        <sender descriptor> 
    
   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. 
    
    
5.3.3 Modification to Resv Message 
    
   <Resv Message> ::=       <Common Header> 
        [ <INTEGRITY> ] 
        [ [<MESSAGE_ID_ACK> |  
                <MESSAGE_ID_NACK>] ... ] 
        [ <MESSAGE_ID> ] 
        <SESSION> 
        <RSVP_HOP> 
        <TIME_VALUES> 
        [ <CALL_ID> ] 
        [ <RESV_CONFIRM> ] 

  
Lin                                                                  6 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
        <SCOPE> 
        [ <NOTIFY_REQUEST> ] 
        [ <ADMIN_STATUS> ] 
        [ <POLICY_DATA> ... ] 
        <STYLE> 
        <flow descriptor list> 
    
   <flow descriptor list> is not modified by this document. 
    
   Note that although the CALL_ID object is optional for GMPLS 
   signaling, this object is mandatory for ASON-compliant networks, 
   i.e., the Resv message must include the CALL_ID object. 
    
    
5.3.4 Modification to PathTear Message 
    
   <PathTear Message> ::= <Common Header> 
        [ <INTEGRITY> ] 
        [ [<MESSAGE_ID_ACK> | 
                <MESSAGE_ID_NACK>] ... ] 
        [ <MESSAGE_ID> ] 
        <SESSION> 
        <RSVP_HOP> 
        [ <CALL_ID> ] 
        [ <sender descriptor> ] 
    
   <sender descriptor> ::= (see earlier definition) 
    
   Note that although the CALL_ID object is optional for GMPLS 
   signaling, this object is mandatory for ASON-compliant networks, 
   i.e., the PathTear message must include the CALL_ID object. 
    
    
5.3.5 Modification to PathErr Message 
    
   <PathErr Message> ::=    <Common Header> 
        [ <INTEGRITY> ] 
        [ [<MESSAGE_ID_ACK> | 
                <MESSAGE_ID_NACK>] ... ] 
        [ <MESSAGE_ID> ] 
        <SESSION> 
        [ <CALL_ID> ] 
        <ERROR_SPEC> 
        [ <ACCEPTABLE_LABEL_SET> ] 
        [ <POLICY_DATA> ... ] 
        <sender descriptor> 

  
Lin                                                                  7 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
    
   <sender descriptor> ::= (see earlier definition) 
    
   Note that although the CALL_ID object is optional for GMPLS 
   signaling, this object is mandatory for ASON-compliant networks, 
   i.e., the PathErr message must include the CALL_ID object. 
    
    
5.3.6 Modification to Notify Message 
    
   Note that this message may include sessions belonging to several 
   calls. 
    
   <Notify message>            ::= <Common Header> 
        [<INTEGRITY>] 
        [ [<MESSAGE_ID_ACK> | 
                <MESSAGE_ID_NACK>] ... ] 
        [ <MESSAGE_ID> ] 
        <ERROR_SPEC> 
        <notify session list> 
    
   <notify session list>       ::= 
        [ <notify session list> ] 
        <upstream notify session> | 
        <downstream notify session> 
    
   <upstream notify session>   ::= <SESSION> 
        [ <CALL_ID> ] 
        [ <ADMIN_STATUS> ] 
        [<POLICY_DATA>...] 
        <sender descriptor> 
    
   <downstream notify session> ::= <SESSION> 
        [ <CALL_ID> ] 
        [<POLICY_DATA>...] 
        <flow descriptor list descriptor> 
    
   Note that although the CALL_ID object is optional for GMPLS 
   signaling, this object is mandatory for ASON-compliant networks, 
   i.e., the Notify message must include the CALL_ID object. 
    
    
6. Support For Behaviors during Control Plane Failures 
    
   Various types of control plane failures may occur within the network. 
   These failures may impact the control plane as well as the data plane. 

  
Lin                                                                  8 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
   As described in [GMPLS-RSVP-TE], current GMPLS restart mechanisms 
   allows support to handle all of these different scenarios, and thus 
   no additional extensions are required. 
    
   In the scope of the ASON model, several optional procedures MAY take 
   place in order to support the following control plane behaviors (as 
   per [G7713] and [IPO-RQTS]): 
    
   -    A control plane node SHOULD provide capability for persistent 
        storage of call and connection state information. This 
        capability allows each control plane node to recover the states 
        of calls/connections after recovery from a signaling controller 
        entity failure/reboot (or loss of local FSM state). Note that 
        although the restart mechanism allows neighbor control plane 
        nodes to automatically recover (and thus infer) the states of 
        calls/connections, this mechanism can also be used for 
        verification of neighbor states while the persistent storage 
        provides the local recovery of lost state. In this case, per 
        [GMPLS-RSVP-TE], if during the Hello synchronization the 
        restarting node determines that a neighbor does not support 
        state recovery (i.e., local state recovery only), and the 
        restarting node maintains its state on a per neighbor basis, the 
        restarting node should immediately consider the Recovery as 
        completed 
   -    A control plane node detecting a failure of all control channels 
        between a pair of nodes SHOULD request an external controller 
        (e.g. the management system) for further instructions, with a 
        default control plane behavior to enter into self-refresh mode 
        (i.e. preservation) for the local call/connection states. As an 
        example, possible external instructions may be to remain in 
        self-refresh mode, or to release local states for certain 
        connections. Specific details are beyond the scope of this 
        document. 
   -    A control plane node detecting that one (or more) connections 
        cannot be re-synchronized with its neighbor (e.g., due to 
        different states for the call/connection) SHOULD request an 
        external controller (e.g., the management system) for further 
        instructions on how to handle the non-synchronized connection. 
        As an example, possible instructions may be to maintain the 
        current local connection states. Specifics of the interactions 
        between the control plane and management plane are beyond the 
        scope of this document. 
   -    A control plane node (after recovering from node failure) MAY 
        lose information on forwarding adjacencies. In this case the 
        control plane node SHOULD request an external controller (e.g., 
        the management system) for information to recover the forwarding 

  
Lin                                                                  9 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
        adjacency information. Specifics of the interactions between the 
        control plane and management plane are beyond the scope of this 
        document. 
    
    
7. Support For Label Usage 
    
   Labels are defined in GMPLS to provide information on the resources 
   used for a particular connection. The labels may range from 
   specifying a particular timeslot, a particular wavelength to a 
   particular port/fiber. In the context of the automatic switched 
   optical network, the value of a label MAY not be consistently the 
   same across a link. For example, the figure below illustrates the 
   case where two GMPLS/ASON-enabled nodes (A and Z) are interconnected 
   across two non-GMPLS/ASON-enabled nodes (B and C), where these nodes 
   are all SDH/SONET nodes providing, e.g., a VC-4 service. 
    
   +-----+                   +-----+ 
   |     |   +---+   +---+   |     | 
   |  A  |---| B |---| C |---|  Z  | 
   |     |   +---+   +---+   |     | 
   +-----+                   +-----+ 
    
   Labels have an associated structure imposed on them for local use 
   based on [GMPLS-SDHSONET] and [GMPLS-OTN]. Once the local label is 
   transmitted across an interface to its neighboring control plane 
   node, the structure of the local label MAY be not significant to the 
   neighbor node since the association between the local and the remote 
   label may not necessarily be the same. This issue does not present a 
   problem in a simple point-to-point connections between two control 
   plane-enabled nodes where the timeslots are mapped 1:1 across the 
   interface. However, in the scope of the ASON, once a non-GMPLS 
   capable sub-network is introduced between these nodes (as in the 
   above figure, where the sub-network provides re-arrangement 
   capability for the timeslots) label scoping MAY become an issue.  
    
   In this context, there is an implicit assumption that the data plane 
   connections between the GMPLS capable edges already exist prior to 
   any connection request. For instance node A's outgoing VC-4's 
   timeslot #1 (with SUKLM label=[1,0,0,0,0]) as defined in [GMPLS-
   SONETSDH]) may be mapped onto node BĘs outgoing VC-4's timeslot #6 
   (label=[6,0,0,0,0]) may be mapped onto node C's outgoing VC-4's 
   timeslot #4 (label=[4,0,0,0,0]). Thus by the time node Z receives the 
   request from node A with label=[1,0,0,0,0], the node Z's local label 
   and the timeslot no longer corresponds to the received label and 
   timeslot information.  

  
Lin                                                                 10 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
    
   As such to support the general case, the scope of the label value is 
   considered local to a control plane node. A label association 
   function can be used by the control plane node to map the received 
   (remote) label into a locally significant label. The information 
   necessary to allow mapping from received label value to a locally 
   significant label value may be derived in several ways: 
    
   -    Via manual provisioning of the label association 
   -    Via discovery of the label association 
    
   Either method may be used. In the case of dynamic association, this 
   implies that the discovery mechanism operates at the timeslot/label 
   level before the connection request is processed at the ingress node. 
   Note that in the simple case where two nodes are directly connected, 
   no association may be necessary. In such instances, the label 
   association function provides a one-to-one mapping of the received to 
   local label values. 
    
    
8. Additional Error Cases 
    
   In the scope of ASON, the following additional error cases are 
   defined: 
    
   -    Policy control failure: unauthorized source; this error is 
        generated when the receiving node determines that a source 
        user/client initiated request for service is unauthorized based 
        on verification of the request (e.g. not part of contracted 
        service). 
   -    Policy control failure: unauthorized destination; this error is 
        generated when the receiving node determines that a destination 
        user/client is unauthorized to be connected with a source 
        user/client. 
   -    Routing problem: diversity not available; this error is 
        generated when a receiving node determines that the requested 
        diversity cannot be provided (e.g. due to resource constraints). 
   -    Routing problem: service level not available; this error is 
        generated when a receiving node determines that the requested 
        service level cannot be provided (e.g. due to resource 
        constraints). 
   -    Routing problem: invalid/unknown connection ID; this error is 
        generated when a receiving node determines that the connection 
        ID generated by the upstream node is not valid/unknown (e.g. 
        does not meet the uniqueness property). Connection ID is defined 
        in [OIF-UNI1]. 

  
Lin                                                                 11 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
   -    Routing problem: no route available toward source; this error is 
        generated when a receiving node determines that there is no 
        available route towards the source node (e.g. due to 
        unavailability of resources). 
   -    Routing problem: unacceptable interface ID; this error is 
        generated when a receiving node determines that the interface ID 
        specified by the upstream node is unacceptable (e.g. due to 
        resource contention). 
   -    Routing problem: invalid/unknown call ID; this error is 
        generated when a receiving node determines that the call ID 
        generated by the source user/client is invalid/unknown (e.g. 
        does not meet the uniqueness property). 
   -    Routing problem: invalid SPC interface ID/label; this error is 
        generated when a receiving node determines that the SPC 
        interface ID (or label, or both interface ID and label) 
        specified by the upstream node is unacceptable (e.g. due to 
        resource contention). 
    
    
9. Security Considerations 
    
   The separation of the call and connection as required for ASON model 
   introduces an additional level of management hierarchy to the 
   connection setup. A connection cannot be used to send user traffic 
   until a call with the same CALL_ID value has been set up. Policy and 
   authentication procedures can be applied to the establishment of the 
   call and then can be restricted to connection establishment within 
   the context of a call. These however should not introduce any 
   additional security issues to the protocol. 
    
    
10. IANA Considerations 
    
   There are multiple fields and values defined within this document. 
   IANA is requested to administer assignment of these class numbers in 
   the FCFS space as shown in [http://www.iana.org/assignments/rsvp-
   parameters]. This document makes suggestions on the assignments given 
   below. 
    
    
10.1 Assignment of New Messages 
    
   No new messages are defined to support the functions discussed in 
   this document. 
    
    

  
Lin                                                                 12 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
10.2 Assignment of New Objects 
    
   Two new objects are defined: 
    
   -    CALL_ID; this object should be assigned an object identifier of 
        the form 11bbbbbb. A suggested value is 227 [TBA].  
    
   -    GENERALIZED_UNI; this object is defined in [OIF-UNI1] with a 
        class-num of the form 11bbbbbb. A suggested value is 229 [TBA]. 
    
    
10.3 Assignment of New Sub-Objects (and Sub-types) 
    
   One new sub-object is defined under the GENERALIZED_UNI object: 
    
   -    SPC_LABEL; this sub-object is part of the GENERALIZED_UNI 
        object, as a sub-type of the EGRESS_LABEL sub-object (which is 
        Type=4). A suggested value is sub-type=2 [TBA]. 
    
    
10.4 Assignment of New Error Code/Values 
    
   No new error codes are required. The following new error values are 
   defined, with the suggested values. Note that certain values were 
   defined with the suggested values in [OIF-UNI1] and are included here 
   for completeness. For error values that have already been assigned by 
   IANA, then those assigned values take precedence over the suggested 
   values below; otherwise the values below are suggested for the error 
   types as described. Error code 02 is defined in [RFC2205], while 
   error code 24 is defined in [RFC3209]. 
    
   02/100 [TBA]: unauthorized source 
   02/101 [TBA]: unauthorized destination 
    
   24/100 [TBA]: diversity not available 
   24/101 [TBA]: service level not available 
   24/102 [TBA]: invalid/unknown connection ID 
   24/103 [TBA]: no route available toward source 
   24/104 [TBA]: unacceptable interface ID 
   24/105 [TBA]: invalid/unknown call ID 
   24/106 [TBA]: invalid SPC interface ID/label 
    
    
11. Acknowledgements 
    


  
Lin                                                                 13 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
   The authors would like to thank Osama Aboul-Magd, Jerry Ash, Sergio 
   Belotti, Greg Bernstein, Adrian Farrel, Nic Larkin, Lyndon Ong and 
   Yangguang Xu for their comments and contributions to the draft. 
    
    
12. References 
    
12.1 Normative References 
    
 
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
      9, RFC 2026, October 1996. 
    
   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997 
    
   [G8080]   ITU-T Rec. G.8080/Y.1304, Architecture for the 
   Automatically Switched Optical Network (ASON), November 2001 
    
   [G7713]   ITU-T Rec. G.7713/Y.1704, Distributed Call and Connection 
   Management (DCM), November 2001 
    
   [OIF-UNI1]   OIF-UNI-01.0, User Network Interface (UNI) 1.0 Signaling 
   Specification 
    
   [RFC2205]   RFC 2205, Resource ReSerVation Protocol (RSVP) -- Version 
   1 Functional Specification, September 1997 
    
   [RFC2961]   RFC 2961, RSVP Refresh Overhead Reduction Extensions, 
   April 2001 
    
   [RFC3209]   RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels, 
   December 2001 
    
   [GMPLS-SIG]   L. Berger (Editor), Generalized MPLS - Signaling 
   Functional Description, draft-ietf-mpls-generalized-signaling-08.txt, 
   April 2002, Work in progress 
    
   [GMPLS-RSVPTE]   L. Berger (Editor), Generalized MPLS Signaling - 
   RSVP-TE Extensions, draft-ietf-mpls-generalized-rsvp-te-07.txt, April 
   2002, Work in progress 
    
   [GMPLS-ASON]   Z. Lin, Requirements for Generalized MPLS (GMPLS) 
   Usage and Extensions For Automatically Switched Optical Network 
   (ASON), draft-lin-ccamp-gmpls-ason-rqts-00.txt, August 2002, Work in 
   progress 

  
Lin                                                                 14 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
    
   [ASON-RQTS]   Y. Xue, Carrier Optical Services Requirements, draft-
   ietf-ipo-carrier-requirements-02.txt, March 2002 
    
   [ITU-LIAISE]   http://www.ietf.org/IESG/LIAISON/ITU-OIF.html 
    
    
12.2 Informative References 
    
   [G807]   ITU-T Rec. G.807/Y.1301, Requirements For Automatic Switched 
   Transport Networks (ASTN), July 2001 
    
   [IPO-RQTS]   O. Aboul-Magd, Automatic Switched Optical Network (ASON) 
   Architecture and Its Related Protocols, draft-ietf-ipo-ason-02.txt, 
   March 2002, Work in progress 
    
    
13. Author's Addresses 
    
   Sergio Belotti 
   Alcatel 
   Via Trento 30, 
   I-20059 Vimercate, Italy 
   Email: sergio.belotti@netit.alcatel.it 
    
   Nic Larkin 
   Data Connection 
   100 Church Street, 
   Enfield 
   Middlesex EN2 6BQ, UK 
   Email: npl@dataconnection.com 
    
   Zhi-Wei Lin 
   Lucent 
   101 Crawfords Corner Road 
   Holmdel, NJ 07733 USA 
   Email: zwlin@lucent.com 
    
   Dimitri Papadimitriou 
   Alcatel 
   Francis Wellesplein 1, 
   B-2018 Antwerpen, Belgium 
   Email: Dimitri.Papadimitriou@alcatel.be 
    
   Dimitrios Pendarakis 
   Tellium 

  
Lin                                                                 15 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
   2 Crescent Place  
   Oceanport, NJ 07757-0901 
   Email: dpendarakis@tellium.com 
    
   Yangguang Xu 
   Lucent 
   1600 Osgood St, Room 21-2A41 
   North Andover, MA  01845-1043 
   Email: xuyg@lucent.com 
    
    








































  
Lin                                                                 16 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
    
Annex A. Normative Information on Structure and Format of the 
GENERALIZED_UNI Object 
    
   The GENERALIZED_UNI object is used to support both the call and soft 
   permanent connection concept. This object's Class-num takes the form 
   11bbbbbb. The general format of this object is as follows(the Class-
   num is the suggested value for the new object): 
    
   GENERALIZED_UNI (Class-num = 229 [TBA], 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 (229)|    C-Type     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Sub-objects                          | 
   ~                              ...                              ~ 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Subobjects: The contents of the GENERALIZED_UNI object are a series 
        of variable-length data items. The common format of the sub-
        objects is shown below: 
    
   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             |     Type      |   Sub-type    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                             Value                             | 
   ~                              ...                              ~ 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   The following sub-objects are defined: 
    
A.1 Source TNA Address Sub-Object 
    
   The Source TNA Address sub-object's Type = 1. The following sub-types 
   are defined: 
    
    
A.1.1 Source TNA Address: IPv4 
    
   For the IPv4 address format, the Sub-type = 1. The Value field of the 
   Sub-object contains the IPv4 address format of the source TNA. See 
   [OIF-UNI1] for format and processing details. 

  
Lin                                                                 17 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
    
    
A.1.2 Source TNA Address: IPv6 
    
   For the IPv6 address format, the Sub-type = 2. The Value field of the 
   Sub-object contains the IPv6 address format of the source TNA. See 
   [OIF-UNI1] for format and processing details. 
    
    
A.1.3 Source TNA Address: NSAP 
    
   For the NSAP address format, the Sub-type = 3. The Value field of the 
   Sub-object contains the NSAP address format of the source TNA. See 
   [OIF-UNI1] for format and processing details. 
    
    
A.2 Destination TNA Address Sub-Object 
    
   The destination TNA Address sub-object's Type = 2. The following sub-
   types are defined: 
    
    
A.2.1 Destination TNA Address: IPv4 
    
   For the IPv4 address format, the Sub-type = 1. The Value field of the 
   Sub-object contains the IPv4 address format of the destination TNA. 
   See [OIF-UNI1] for format and processing details. 
    
    
A.2.2 Destination TNA Address: IPv6 
    
   For the IPv6 address format, the Sub-type = 2. The Value field of the 
   Sub-object contains the IPv6 address format of the destination TNA. 
   See [OIF-UNI1] for format and processing details. 
    
    
A.2.3 Destination TNA Address: NSAP 
    
   For the NSAP address format, the Sub-type = 3. The Value field of the 
   Sub-object contains the NSAP address format of the destination TNA. 
   See [OIF-UNI1] for format and processing details. 
    
    
A.3 Diversity Sub-Object 
    


  
Lin                                                                 18 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
   The Diversity sub-object's Type = 3. For this sub-object, one sub-
   type is currently defined: Sub-type = 1. The Value field of the sub-
   object contains the rules for connection diversity. See [OIF-UNI1] 
   for format and processing details. 
    
    
A.4 Egress Label Sub-Object 
    
   The Egress Label sub-object's Type = 4. For this sub-object, two sub-
   types are defined:  
    
   Sub-type = 1; This sub-type is referred to as the EGRESS_LABEL sub-
   object. See [OIF-UNI1] for format and processing details. 
    
   Sub-type = 2; This sub-type is referred to as the SPC_LABEL. See 
   above (Section 4, Soft Permanent Connection) for description of this 
   sub-object.  
    
    
A.5 Service Level Sub-Object 
    
   The Service Level sub-object's Type = 5. For this sub-object, one 
   sub-type is currently defined: Sub-type = 1. The Value field of the 
   sub-object contains the service level specification requested by the 
   user. See [OIF-UNI1] for format and processing details. 
    























  
Lin                                                                 19 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
    
Appendix I. Non-Normative Extensions for Supporting Complete Separation 
of Call and Connection 
    
   This section describes the optional and non-normative capability to 
   support complete separation of call and connection. To support 
   complete separation of call and connection, a call capability object 
   is introduced. 
    
    
I.1 Call Capability 
    
   A call capability is used to specify the capabilities supported for a 
   call. For RSVP-TE a new CALL_OPS object is defined to be carried by 
   the Path, Resv, PathTear, PathErr, and Notify message. The CALL_OPS 
   object also serves to differentiate the messages to indicate a "call-
   only" call. In the case for logical separation of call and 
   connection, the CALL_OPS object is not needed. 
    
   The CALL_OPS object is defined as follows (the Class-num is the 
   suggested value for the new object): 
    
   CALL_OPS (Class-num = 228 [TBA], 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 (228)|  C-Type (1)   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                Reserved                       | Call ops flag | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
   Two flags are currently defined for the "call ops flag": 
        0x01: call without connection 
        0x02: synchronizing a call (for restart mechanism) 
    
    
I.2 Complete Separation of Call and Connection (RSVP-TE Extensions) 
    
   A complete separation of call and connection implies that a call 
   (during steady state) may have zero (or more) associated connections. 
   A zero connection call is a steady state, e.g., simply setting up the 
   user end-point relationship prior to connection setup. The following 
   modified messages are used to set up a call. Set up of a connection 
   uses the messages defined in Section 5 above.  
    

  
Lin                                                                 20 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
    
I.2.1 Modification to Path 
    
   <Path Message> ::=    <Common Header> 
        [ <INTEGRITY> ] 
        [ [<MESSAGE_ID_ACK> |  
                <MESSAGE_ID_NACK>] ... ] 
        [ <MESSAGE_ID> ] 
        <SESSION> 
        <RSVP_HOP> 
        <TIME_VALUES> 
        [ <EXPLICIT_ROUTE> ] 
        <LABEL_REQUEST> 
        <CALL_OPS> 
        <CALL_ID> 
        [ <NOTIFY_REQUEST> ] 
        [ <ADMIN_STATUS> ] 
        <GENERALIZED_UNI> 
        [ <POLICY_DATA> ... ] 
        <sender descriptor> 
    
   The format of the sender descriptor for unidirectional LSPs is: 
    
   <sender descriptor> ::=  <SENDER_TEMPLATE> 
        <SENDER_TSPEC> 
        [ <RECORD_ROUTE> ] 
    
   The format of the sender descriptor for bidirectional LSPs is: 
    
   <sender descriptor> ::=  <SENDER_TEMPLATE> 
        <SENDER_TSPEC> 
        [ <RECORD_ROUTE> ] 
        <UPSTREAM_LABEL> 
    
   Note that LABEL_REQUEST, SENDER_TSPEC and UPSTREAM_LABEL are not 
   required for a call; however these are mandatory objects. As such, 
   for backwards compatibility purposes processing of these objects for 
   a call follows the following rules: 
    
   -    These objects are ignored on receipt; however, a valid-formatted 
        object (e.g., by using the received valid object in the 
        transmitted message) must be included in the generated message. 
    
    
I.2.2 Modification to Resv 
    

  
Lin                                                                 21 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
   <Resv Message> ::=       <Common Header> 
        [ <INTEGRITY> ] 
        [ [<MESSAGE_ID_ACK> |  
                <MESSAGE_ID_NACK>] ... ] 
        [ <MESSAGE_ID> ] 
        <SESSION> 
        <RSVP_HOP> 
        <TIME_VALUES> 
        <CALL_OPS> 
        <CALL_ID> 
        [ <RESV_CONFIRM> ] 
        [ <NOTIFY_REQUEST> ] 
        [ <ADMIN_STATUS> ] 
        [ <POLICY_DATA> ... ] 
        <STYLE> 
        <flow descriptor list> 
    
   <flow descriptor list> ::=  
        <FF flow descriptor list> 
                | <SE flow descriptor> 
    
   <FF flow descriptor list> ::= 
        <FLOWSPEC> 
        <FILTER_SPEC> 
        [ <RECORD_ROUTE> ] 
        | <FF flow descriptor list> 
        <FF flow descriptor> 
   <FF flow descriptor> ::=  
        [ <FLOWSPEC> ] 
        <FILTER_SPEC> 
        [ <RECORD_ROUTE> ] 
    
   <SE flow descriptor> ::= 
        <FLOWSPEC>  
        <SE filter spec list> 
   <SE filter spec list> ::= 
        <SE filter spec> 
        | <SE filter spec list> 
        <SE filter spec> 
   <SE filter spec> ::=  
        <FILTER_SPEC> 
        [ <RECORD_ROUTE> ] 
    
   Note that FILTER_SPEC and LABEL are not required for a call; however 
   these are mandatory objects. As such, for backwards compatibility 


  
Lin                                                                 22 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
   purposes processing of these objects for a call follows the following 
   rules: 
    
   -    These objects are ignored on receipt; however, a valid-formatted 
        object (e.g., by using the received valid object in the 
        transmitted message) must be included in the generated message. 
    
    
I.2.3 Modification to PathTear 
    
   <PathTear Message> ::= <Common Header> 
        [ <INTEGRITY> ] 
        [ [<MESSAGE_ID_ACK> | 
                <MESSAGE_ID_NACK>] ... ] 
        [ <MESSAGE_ID> ] 
        <SESSION> 
        <RSVP_HOP> 
        <CALL_OPS> 
        <CALL_ID> 
        [ <sender descriptor> ] 
    
   <sender descriptor> ::= (see earlier definition in this section) 
    
    
I.2.4 Modification to PathErr 
    
   <PathErr Message> ::=    <Common Header> 
        [ <INTEGRITY> ] 
        [ [<MESSAGE_ID_ACK> | 
                <MESSAGE_ID_NACK>] ... ] 
        [ <MESSAGE_ID> ] 
        <SESSION> 
        <CALL_OPS> 
        <CALL_ID> 
        <ERROR_SPEC> 
        [ <POLICY_DATA> ... ] 
        <sender descriptor> 
    
   <sender descriptor> ::= (see earlier definition in this section) 
    
    
I.2.5 Modification to Notify 
    
   <Notify message>            ::= <Common Header> 
        [<INTEGRITY>] 
        [ [<MESSAGE_ID_ACK> | 

  
Lin                                                                 23 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
                <MESSAGE_ID_NACK>] ... ] 
        [ <MESSAGE_ID> ] 
        <ERROR_SPEC> 
        <notify session list> 
    
   <notify session list>       ::= 
        [ <notify session list> ] 
        <upstream notify session> | 
        <downstream notify session> 
    
   <upstream notify session>   ::= <SESSION> 
        <CALL_ID> 
        [ <ADMIN_STATUS> ] 
        [<POLICY_DATA>...] 
        <sender descriptor> 
    
   <downstream notify session> ::= <SESSION> 
        <CALL_ID> 
        [<POLICY_DATA>...] 
        <flow descriptor list descriptor> 
    
    
I.3 IANA Considerations 
    
   This Appendix defines a new object to support complete separation of 
   call and connection. IANA is requested to administer assignment of 
   these new values from the FCFS range within the RSVP parameters. This 
   document makes suggestions on the assignments given below. 
    
    
I.3.1 Assignment of New Object 
    
   One new object is defined: 
    
   -    CALL_OPS; this object should be assigned an object identifier of 
        the form 11bbbbbb. A suggested value is 228 [TBA].  
    
    










  
Lin                                                                 24 

                        GMPLS RSVP-TE for ASON             August 2002 
 
 
    
Full Copyright Statement 
    
   "Copyright (C) The Internet Society (2002). All Rights Reserved.  
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph are 
   included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS 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. 
    
    
    


















  
Lin                                                                 25