Internet DRAFT - draft-xu-ccamp-gmpls-sig-reorg

draft-xu-ccamp-gmpls-sig-reorg



Network Working Group                                
Internet Draft                                      Yangguang Xu 
Expiration Date: September 2001                      Zhi-Wei Lin
                                                  Maarten Visses
                                           Siva Sankaranarayanan

                                        Lucent Technologies, Inc.
                                                     



                     Modification and Reorganization 
               to GMPLS Signaling Functional Specification

                  draft-xu-ccamp-gmpls-sig-reorg-00.txt




1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.



2. Abstract

   This draft is based on [GMPLS-ARCH], [GMPLS-SIG] and [GMPLS-SIGEN]. 
   It proposes re-organization and modification to current GMPLS signaling 
   [GMPLS-SIG] and specifies a set of objects that are common to different 
   network interfaces. Changes from [GMPLS-SIG] are:

   -- G-Label Request and G-Label objects are re-formatted. 

   -- Upstream Label, Suggested Label and Label Set are merged into 
      one Suggested Label Set. 

   -- Bi-directional LSP creation procedure is clarified and simplified.

   -- Notification/Request and ER Objects are enhanced.



Y. Xu et al.                                                      Page [1]

Internet Draft          GMPLS Signaling Reorganization            March 2001
   

3. Introduction

   Signaling protocols are essential to enable ASTN. MPLS based signaling 
   has been proposed to IETF as an option for ASTN control plane. However a 
   protocol is always designed and optimized for a certain application and 
   environment. None of existing signaling protocols could be applied 
   directly to ASTN with simple extensions. Negative aspects of applying 
   them directly to ASTN should also be clarified. Modifications are needed 
   in different scales. 

   In order to reuse and optimize MPLS protocols for ASTN, it's indeed 
   critical to start from understanding how circuit switches are operated. 
   Beginning from existing protocols could twist the nature of the 
   application and generate messy solutions. This draft is based on 
   [GMPLS-ARCH], [GMPLS-SIG] and [GMPLS-SIGEN] and specifies a set of 
   objects that are common to different network interfaces. Even this draft 
   is targeted to GMPLS signaling; objects defined here should be 
   applicable to other protocols too.


4. Abstract Signaling Messages and Associated GMPLS Objects

   GMPLS signaling is used for path operations and consists a set of 
   messages. They are Create/Response, Restoration/Response, 
   Delete/Response, Modify/Response, Query/Response and Notification. 
   Objects specified in this draft and [GMPLS-SIG] are mainly associated 
   with Create/Response messages. These objects are:

   -- For Create Request: 
 
      G-Label Request                                     (Mandatory)
      Explicit Route                                      (Optional)
      Suggested Label Set                                 (Optional)
      Explicit Label                                      (Optional)

   -- For Create Response:
      G-Labels                                            (Optional)
      LSP ID                                              (Mandatory)
      Connection Status/Error Code                        (Mandatory)

   Following sections elaborate details of each change. 



5. Generalized Label Request  

5.1 Reason for Modification

    -- G-label request is equivalent to connection request. It's desirable 
       to have a common label request format for different technologies.
   
    -- Related components should be glued together into one meaningful 
       field.



Y. Xu et al.                                                      Page [2]

Internet Draft          GMPLS Signaling Reorganization            March 2001


    -- Services offered and layer at which the service is offered needs to 
       be consistent with both ITU (for SDH and OTN) and ANSI (for SONET) 
       recommendations.  

    -- OTN related service offerings and analog signals (non-OEO) should be 
       covered.

    -- G-PID should be associated with each signal type instead of only 
       with LSP encoding type

    -- LSP Enc. Type, Signal Type, RGT, RNC in [GMPLS-SIG] and 
       [GMPLS-SIGEN] have redundant information and are meaningful only  
       interpreted together. Also RNC may be interpreted inconsistently. 
       For example, RNC could be the "3" STS-3c or the STS-"3"V.

    -- The scope of Protection Flag should be extended.


5.2 Specification

     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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    | LSP Enc. Type |                Signal Type                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |  Service Type |  Dir  | Rserved |           G-PID             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    LSP Encoding Type and Signal Type together identify the specific 
    signal type of the LSP. 


    LSP Encoding Type: 8 bit 

    Indicates the encoding technology of the LSP being requested. Below, 
    only LSP Encoding Types that are meaningful to ASTN are specified.

    
                 Value        Type
                 -----        --------
                 3            ANSI PDH
                 4            ETSI PDH
                 5            SDH
                 6            SONET
                 7            OTN
                 8            Analog 

    
    Signaling Type: 24 bits 

    Indicates the specific signal type of the LSP being requested. This 
    field is interpreted according to the technology specified by LSP 
    Encoding Type. The Signal Type provides transit switches with the 
 


Y. Xu et al.                                                      Page [3]

Internet Draft          GMPLS Signaling Reorganization            March 2001
    

    information required to determine which link connection can support 
    the LSP. This field is technology dependent. Detailed formats for each 
    Encoding Type are defined at [GLABEL-REQ].


    G-PID: 16 bits
 
    Indicates the payload carried by an LSP, i.e. an identifier of the 
    client layer of the LSP.  It's the same as Payload Types in G.709, 
    Signal Label in G.707 and L3PID in RSVP-TE. Each of signal type may 
    only allow certain types of client signals. The G-PID is mainly used by 
    the adaptation layer function at the LSP terminating points. G-PID is 
    also technology dependent. Details are covered by [GLABEL-REQ].


    Directionality: 2 bits

    Indicates the direction of the LSP

                 Value        Type
                 -----        --------
                 1            Transmit	
                 2            Receive			
                 3            Bi-directional	


    Service Type: 8 bits

    Similar to Service Type defined in [OIF-UNI], Service Type field 
    indicates a class of service.  A carrier may specify a range of 
    different classes of service (e.g. gold, silver, bronze) with 
    predefined characteristics (e.g. restoration plans). The pre-defined 
    service types may correspond to different types of restoration (e.g. 
    no restoration, 1+1 protection, shared protection and etc.), 
    connection set-up and hold priorities, reversion strategies for the 
    connection after failures have been repaired, and retention 
    strategies. The structure and semantics related to this field can be 
    extended by the provider. 


6. ER Object Extension

   Current ER Object/TLV covers AS, LSP ID and Node ID. For ASTN, it 
   should be extended to Logical Link (Bundle) granularity. 


6.1 Reason for Extension
    
   In ASTN, a Logical Interface ID is assigned to a set of physical 
   interfaces that share common logical or physical attributes that 
   are significant for path selection. Link state database is normally in 
   logical link granularity; so does the result of path selection, the ER 
   object/TLV. 



Y. Xu et al.                                                      Page [4]

Internet Draft          GMPLS Signaling Reorganization            March 2001


   The Logical Interface ID Object contains two pieces of information, a node 
   ID and a Logical Interface ID which is unique locally to the NE.


6.2 Specification

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                   Node ID                                    //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Logical Interface ID                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   
   Node ID: 32 bits for IPv4, 128 bits for IPv6 Address or 
            160 bits for NSAP address


   Logical Interface ID: 32 bits
   
   This ID is the handle for a logical interface. It's different 
   from the physical interface ID. 
 


7. Generalized Label 

7.1 Reason for Change

    -- What is Label? Label is associated with a specific switchable data 
       flow. This definition is generic and can be applied to different 
       technologies.       

    -- Cross connect (matrix connection in ITU-T term) is an internal 
       connection between two specific external/internal interfaces. 
       
       To GMPLS signaling, we only care about connections between external 
       interfaces. Internally, a connection between two external interface may 
       consist several internal connections which are invisible to external. 
       
       So to ASTN, a label is used to identify a specific external interface 
       and equivalent to a tributary slot identifier, for example, an analogy 
       optical signal, a STS-48c, or a STS-3c within a OC48 port.
 
       Different from packet switched network, in ASTN, a label is 
       bound with a specific "physical" resource. 
    
    -- Label has per interface or per platform scope. To ASTN, because 
       out-of-band (non-associated) signaling is normally used, label by 
       default is per platform based. 





Y. Xu et al.                                                      Page [5]

Internet Draft          GMPLS Signaling Reorganization            March 2001


    -- For ASTN, paths are normally bi-directional. Correspondingly, a 
       physical interface ID may identify two physical ports (one IN, one 
       OUT). However, this is not mandatory. Transmit and receive ports may 
       have different port IDs. These concepts also apply to the logical 
       interfaces. So a label in ASTN has directionality. 

    -- New label formats for OTN should be defined in case ITU defines OTN 
       multiplexing structure.

    -- In order to support LSP tunneling, two types of label formats are 
       needed. <1> Basic Format and  <2> Hierarchical Format.


7.1.1 Basic Label Format
    
   In order to define a label's basic format, we should understand how 
   external interfaces are normally represented in circuit switches. 
   Typically, a specific external interface can be identified as a 
   concatenation of a physical port ID and channel ID within the port 
   (assuming non-blocking switch fabric).


7.1.2 Hierarchical Format

   When a low granularity LSP tunnels through a pre-established high 
   granularity LSP, the high granularity LSP works as an ATM VPC. 
   Label format is then the concatenation of the high granularity 
   Connection/Tunnel ID and the low granularity Channel ID within it.

   Hierarchical format is a more generic form. Connection ID can be treated 
   as a logical port ID and identifies a pre-occupied physical interface. 
   
   The hierarchical label forms a stack that enables LSP tunneling at 
   an arbitrary level, with the Basic Label Format at the stack bottom.


7.2 Specification

7.2.1 Basic Format

     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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                  G-Label     (Port ID)                        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    | D |              G-Label     (Channel ID)                     | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Directionality: 2 bits
   
   Indicates the direction of this label:




Y. Xu et al.                                                      Page [6]

Internet Draft          GMPLS Signaling Reorganization            March 2001


                 Value        Type
                 -----        --------
                 1            Transmit( Out )
                 2            Receive ( In )
                 3            Bi-directional


   G-Label Port ID: 32 bits
   
   Indicates the port ID or unnumbered interface ID. For circuit switched 
   Network Element (NE), physical ports don't have IP addresses. They are 
   either identified with a string or an unnumbered index. Port IDs are 
   product dependent. Different vendors may have different naming and 
   addressing structures for their products. However, an NE's Port ID 
   structure is only meaningful to the NE itself. To its neighbor, an NE's    
   port ID discloses no semantics and is only used as part of an index for 
   Port Association Table look-up. [GMPLS-ARCH]


   The G-Label Channel ID: 32 bits. 
    
   Indicates the Channel ID within the physical port. Channel IDs are 
   technology dependent. Generally, there are different multiplexing 
   structures for different technologies. For two physical ports connected 
   by a physical medium, these two ports should share common physical 
   attributes including multiplexing structure, which are technology 
   specific and clearly defined by standards.

   The Channel ID structure is technology dependent and defined in [GMPLS-
   SIG] and [LABEL-REQ].
   

7.2.2 Hierarchical Format

     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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    //                 G-Label     (Connection ID)                  // 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    | D |              G-Label     (Channel ID)                     | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Directionality: 2 bits
   
   Indicates the direction of this label. Same as 7.2.1

 
   G-Label Connection ID: TBD
 
   An Connection ID is a unique identifier of a pre-established connection. 
   It is normally used at the sub-network boundary or client/server 
   interface and remains constant in the connection service life. Inside of 



Y. Xu et al.                                                      Page [7]

Internet Draft          GMPLS Signaling Reorganization            March 2001


   the sub-network, there may be several LSP IDs (used within a sub-network 
   for connection management) associated with this Connection ID according to 
   the connection service type. For example, a 1+1 protected 


   connection has two LSP IDs associated with its Connection ID, while an 
   STS-xV connection has x LSP IDs associated with its Connection ID. 

   When Connection ID across network boundary, it should be globally unique.

   
   The G-Label Channel ID: 32 bits. 
     
   Same as 7.2.1. For example, it can be specified in KLM format [GMPLS-SIG] 
   for a Low Order (LO) SONET/SDH LSP.



8. Suggested Label Set 

8.1 Reason for Change
         
   -- Using Upstream Label for bi-directional LSP creation is not 
      necessary. Let's see how a bi-directional LSP is created.

      <1> In case a NE's physical interfaces are bi-directional (the 
          default case), a single bi-directional label is enough.

      <2> In case a NE's physical interfaces are uni-directional, either 
          upstream node or downstream node can specify labels for both 
          directions. For implementation simplicity, it's better for single
          node to specify both labels.

   -- Suggested Label and Label Set are mutually exclusive. 

   -- For certain LSP creation, for example, a virtual concatenated STS-3 
      LSP, more than one suggested label is required. 


8.2 Specification

    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |           Reserved            |    Type     |     Action      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   //              	G-label                                    //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   :                               :                               :
   :                               :                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   //              	G-label                                    //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 



Y. Xu et al.                                                      Page [8]

Internet Draft          GMPLS Signaling Reorganization            March 2001


   Action: 8 bits 
   
                 Value        Type
                 -----        --------
                 1            Inclusive List
                 Indicates that the object/TLV includes labels that 
                 downstream node has to choose from
                 2            Exclusive List
                 Indicates that the object/TLV includes labels that 
                 downstream node has to exclude 
                 3            Inclusive Range
                 Indicates that the object/TLV includes the label range 
                 that downstream node has to choose from
                 4            Exclusive Range
                 Indicates that the object/TLV includes the label range 
                 that downstream node has to exclude
                 5            Strict Set
                 Works as suggested labels.
 
   If labels are un-directional, for a bi-directional request, transmit label 
   and receive label should be adjacent in this object.


   Type: 8 bits
   
   Indicate the label type. All labels within a suggested label set object 
   should have the same label type. 


   G-label: variable bits
   
   Specifies a label without object wrapper.
   


9. Notification Request and Notification

9.1 Reason for Change
   
   -- One fundamental difference between ASTN and packet switched network 
      is that the transport (data) plane in ASTN is independent of the 
      control plane. Notification should be created (for RSVP-TE) or 
      enhanced (for CR-LDP) to cover both transport and control plane 
      events.
 
   -- In order for node to have a better control of what type of events it 
      wants to be notified, an optional Event Type field is added. 









Y. Xu et al.                                                      Page [9]

Internet Draft          GMPLS Signaling Reorganization            March 2001


9.2 Specification

9.2.1 Notification Request

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                    Notify Node Address                       //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Event Number         |          Event Type             |                      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                     Event types                              //                      
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Notify Node Address: 32 bits for IPv4, 128 bits for IPv6 or 160 bits 
   for NSAP
   
   Indicates the control entity IP address that should be notified when an 
   event(s) happens. 


   Event Number: 16 bits
   
   Indicates the number of Event Types a node want to be notified. If 
   Event Number field is all "1". All events will be notified. 

   
   Event Type: 8 bits
   
   Indicates the events that the control node is willing to be notified. 
   Event types are associated with Error code/subcode defined below. Types 
   are TBD. 


9.2.2 Notification

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Status/Error        |    Status/Error Subcode         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Status/Error Code: 16 bits
  
   Status/Error Subcode: 16 bits

   Together, they indicate specific status/error of both control plane and 
   transport plane. Code numbers are TBD.


9. Security Considerations

   This document raises no new security concerns for MPLS signaling.



Y. Xu et al.                                                      Page [10]

Internet Draft          GMPLS Signaling Reorganization            March 2001


10. References

[GMPLS-SIG]       P. Ashwood-Smith, et. al., "Generalized MPLS - Signaling 
Functional Description", Work in Progress, Nov. 2000.

[GMPLS-ARCH]      Y. Xu, et. al.,  "GMPLS Control Plane Architecture for 
ASTN", Work in Progress, Nov. 2000.

[GMPLS-SIGEN]     B. Mack-Crane, et. al., "Enhancements to GMPLS Signaling for 
Optical Technologies", Work in Progress, Nov. 2000.

[GLABEL-REQ]	M. Visses, et. al., "Generalized Label Request and Label 
Specification", Work in Progress, March 2001.

[OIF-UNI]		Many, "OIF UNI Signaling Specification", OIF2000.125.3, Work 
in Progress, Feb. 2001.



11. Author Information
    
    Yangguang Xu
    21-2A41, 1600 Osgood Street
    Lucent Technologies, Inc.
    North Andover, MA 01845
    Email:	xuyg@lucent.com
   
    Zhi-Wei Lin
    101 Crawfords Corner Rd
    Lucent Technologies, Inc.
    Holmdel, NJ  07733-3030 
    Email: zwlin@lucent.com

    Siva Sankaranarayanan    
    101 Crawfords Corner Rd
    Lucent Technologies, Inc.
    Holmdel, NJ  07733-3030 
    Email: siva@hotair.hobl.lucent.com

    Maarten Visses
    HD-3-18
    Botterstraat 45
    Postbus 18
    Lucent Technologies, Inc.
    Huizen,   1270 AA  Netherlands 











Y. Xu et al.                                                      Page [11]