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]