MPLS Working Group Yanhe Fan, Peter Ashwood-Smith (Nortel Networks) Internet Draft Vishal Sharma, Ken Owens (Tellabs) Gerald R. Ash (AT&T) Murali Krishnaswamy, Yang Cao (Lucent Technologies) M. K. Girish (SBC Technology Resources, Inc.) Herbert M. Ruck (Packet Network Services) Simon Bernstein, Phuc Nguyen (Global One) Sunil Ahluwalia (Trillium Digital Systems) Hans Sjostrand (Ericsson) Klas Eriksson (Utfors AB) Lihshin Wang(QwestCommunications) Avri Doria (Nokia Telecommunications) Heinrich Hummel (Siemens AG) Expiration Date: September 2000 March 2000 Extensions to CR-LDP and RSVP-TE for Optical Path Set-up draft-fan-mpls-lambda-signaling-00.txt 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. Abstract Real-time optical path setup is a fundamental requirement for agile optical networks and signaling is a mechanism to achieve automatic fast path setup. Our objective is to define extensions to both CR- LDP and RSVP-TE that address this requirement. CR-LDP and RSVP-TE 1 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 are defined in [CR-LDP] and [RSVP], respectively, for path setup within a MPLS domain. In this draft, we specify mechanisms, TLVs and Objects required to support Optical Label Switched Path setup. Table of Contents 1. Introduction 2. Agile Optical Network Overview 2.1 Compatibility Check 2.2 Optical User-Network Interface Check 2.3 Optical Information Distribution 2.4 Composite Labels 3. Extensions to CR-LDP 3.1 Messages and TLVs that are affected by the extensions 3.1.1 Initialization Message 3.1.2 Label Request Message 3.1.3 Label Mapping Message 3.1.4 Notification Message 3.1.5 Release, Withdraw and Abort Messages 3.2 Optical TLV Extensions 3.2.1 Optical Session Parameters TLV 3.2.2 Optical Interface Type TLV 3.2.2.1 Service Type Mask 3.2.2.2 Control Protocol Mask 3.2.3 Optical Trail Descriptor TLV 3.2.4 Optical Label TLV 3.2.5 Lambda Set TLV 4. Extensions to RSVP-TE 4.1 Messages and Objects that are affected by the extensions 4.1.1 Path Message 4.1.2 Resv Message 4.1.3 PathErr and ResvErr Messages 4.2 Optical Object Extensions 4.2.1 Optical Label Request Object 4.2.2 Optical Interface Type Object 4.2.3 Optical Trail Descriptor Object 4.2.4 Optical Label Object 4.2.5 Lambda Set Object 5. Processing of Optical TLVs and Optical Objects 5.1 Processing of Optical Session Parameters TLV/Optical Label Request Object 5.2 Processing of Optical Interface Type TLV/Object 5.3 Processing of Optical Trail Descriptor TLV/Object 5.4 Processing of Optical Label TLV/Object 5.5 Processing of Lambda Set TLV/Object 5.6 Error codes 6. Security Considerations 7. References 8. Acknowledgements 9. Authors' Addresses Appendix A Fan et al. Expires September 2000 2 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 1. Introduction There has been an increasing interest recently in agile optical networks. Agility in optical networks implies fast end-to-end optical path setup and restoration. One way to set up an optical path through an agile optical network quickly is to use signaling together with dynamic routing. Routing is used to collect information on network topology and resources, pass states around and compute the optimal paths from one node to the others. Signaling is used to setup, maintain, modify/renegotiate and tear down these paths. CR-LDP and RSVP-TE are defined in [CR-LDP] and [RSVP], respectively. They both support constraint-based routed label switched paths. Therefore, it is natural to extend them to set up optical paths in an agile optical network. The extensions defined in this draft provide support for Optical Label Switched Path (OLSP) setup, maintenance, and teardown in optical networks by introducing five new types of TLVs/Objects and procedures related to CR-LDP/RSVP-TE. 2. Agile Optical Network Overview An optical MPLS-enabled network consists of Optical Label Switching Routers (OLSR) and point-to-point links. The OLSRs are interconnected by links in a mesh topology. There are two types of interfaces in this network: Optical Node-to-Node Interface (ONNI) between two OLSRs and Optical User-Network Interface (OUNI) between customer premise equipment (CPE) and OLSRs. The signaling protocol defined in this draft may serve as part of both ONNI and OUNI. An agile MPLS-enabled optical network is an optical network with fast OLSP setup and restoration. In this network, the control component of an OLSR consists of a routing protocol (OSPF or IS-IS, for example) and a signaling protocol (CR-LDP or RSVP-TE, for example). All control information can be exchanged through dedicated control channels or independent signaling networks as discussed in [Sigarch] and [OLXC]. The means to accomplish this is for further study. An OLSR can be anyone of the following types of optical cross- connects equipped with the control component described above: 1. Switching at fiber level 2. Cross-connect at Lambda level only 3. Cross-connect at sub-Lambda level only (for an example, SONET/SDH DXCs, etc.) 4. Cross-connect at both Lambda and sub-Lambda levels An OLSR can be a Lambda conversion-capable (CC) OLSR or a Lambda conversion-incapable (CI) OLSR. A CC-OLSR is an OLSR that is capable of cross connecting between any wavelengths, and a CI-OLSR is one Fan et al. Expires September 2000 3 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 that can only cross-connect the same wavelength between different interfaces. There are two types of links, service-transparent (ST) links and service-aware (SA) links. A ST-link is a link providing transparent bit transmission, and the interfaces on both ends of this link simply perform bitwise input and output operation. An ST-Link can accept data at any bit rate below a certain maximum bit rate and any protocol format. A pure optical link in which the signal remains in optical form from the link input interface to the link output interface is an example of a ST-link. An SA-link is a link in which interfaces on both ends will handle the payload according to protocol format and/or data bit rate before transmitting and after receiving. An OC-192 link is an example of a SA-link. In an MPLS-enabled optical network, an LSP is an optical path between two OUNIs. An LSP may consist of a fiber bundle, just single fiber, the concatenation of multiple Lambdas, just one Lambda, groups of sub-Lambda channels, or just one sub-Lambda. The label in an MPLS-enabled agile optical network may represent any of the following: 1. A fiber bundle 2. An arbitrary number of fibers in that bundle 3. A single fiber 4. An arbitrary number of Lambdas within a fiber 5. A single Lambda 6. An arbitrary number of sub-Lambda channels 7. A single sub-Lambda channel In the proposal described in [Lambda], a Lambda is the granularity of an OLSP. We believe that Lambda granularity is too coarse for a number of reasons: 1) Bandwidth management and allocation is one issue. We may have, for example, an OC-48 encoding Lambda coming into an OLSR and OC-192 encoding Lambda going out of this OLSR. If our allocation granularity is only at the Lambda level, we must map the OC-48 to an entire OC-192 pipe and, therefore, we waste three quarters of the bandwidth. 2) Scalability is another issue. Many routers are interconnected through an optical network, which requires a lot of optical paths among them. We may have a similar "n squared" problem that classical IP over ATM has because we don't want the traffic to cross the optical network twice even we can have the direct optical path between the source and destination. We may quickly run out of Lambdas if these optical paths are Lambda paths, as opposed to sub- Lambda paths. The development of Lambda merging technology may alleviate this problem. However, this type of technology is not available yet. In this draft the granularity of OPLS can be multiple fibers, a single fiber, multiple Lambdas, a single Lambda, different Fan et al. Expires September 2000 4 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 levels of sub-Lambdas, and groups at all fiber, Lambda and sub- Lambda levels. The Optical Trail Descriptor (OTD) contains the attributes of an optical trail. OTD defines the service type and the channel group. The service type can be SONET, Ethernet, etc. The Channel group can be a Lambda group, an OC-48 group, etc. The Optical Interface Type (OIT) defines the OUNI types. When an OLSP Request is generated, the OTD and requested OIT of OUNI interface of the egress OLSR must be specified. 2.1 Compatibility Check To set up an OLSP in agile optical networks, we must make sure that all links crossed by the OLSP are compatible with the OTD. The compatibility check must be performed at each SA-link. A new type of TLV/Object, OTD TLV/Object is defined to encode the OTD information. ST or SA information is the property of links. The routing protocol will carry this information. When ER-LSPs are calculated, this information will be taken into consideration. 2.2 Optical User-Network Interface Check To set up an OLSP in agile optical networks, we must make sure that both the input interface of the ingress OLSR and the output interface of the egress OLSR have the same type of OUNI. The OUNI check must be performed at the egress OLSR or at both the Ingress and the Egress OLSRs. A new type of TLV/Object, the OIT TLV/Object, is defined to encode the OIT information. A routing protocol may carry optical interface information about particular OUNI, and may take this information into account when computing paths for optical trails. 2.3 Optical Information Distribution In order to propagate optical state information and calculate the available paths, extensions to OSPF/IS-IS are defined in [ROUTING]. The Optical LSA/LSP extension advertises the available resource information. This extension is an opaque LSA/LSP. 2.4 Composite Labels The signaling protocols for MPLS explicitly routed LSPs use a label which is passed backwards from destination to source to construct the actual data-path. As each label is received for a particular output, a new label is allocated for the corresponding input. Thus the switching from input label/interface to output label/interface is programmed. To accommodate the switching of entire fibers, Lambdas within those fibers and sub-Lambdas, we introduce the concept of a composite label. This composite label allows the Fan et al. Expires September 2000 5 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 signaling protocol to establish entire fiber/Lambda and/or sub- Lambda paths using a single end to end mapping/resv message without having to run recursive instances of the signaling protocol. Composite labels do not however preclude the use of recursive signaling instances should this prove necessary for administrative or scalability reasons. One important effect of a composite label is that sub-Lambdas may result in the allocation of new Lambda, which may in turn result in the allocation of entire fibers. A composite label has a somewhat complex TLV format, so as an aid to understanding them we introduce the following ASCII representation for a composite label: { *.*.* }* Composite labels travel within a mapping/resv message and behave in a manner similar to normal shim or other in-band labels. This means that a mapping/resv message can control the switching of an entire fiber on some input bundle to an entire fiber on some output bundle, an entire Lambda to a corresponding Lambda, or a sub-Lambda to sub- Lambda. Many other mapping/sub-mapping combinations exist, and what is legal is dictated by what is supported by the switching hardware being traversed. Example: The receipt of mapping/resv with the label F7.*.* may cause the generation of a mapping/resv with the label F4.*.*. The result would be that fiber 4 on the input bundle would be mapped entirely to fiber 7 on the output bundle. Example: The receipt of mapping/resv with the label F7.L4.* may cause the generation of a mapping/resv with the label F4.L62.*. The result would be that the fiber 4, Lambda 62 would be mapped completely to fiber 7 Lambda 4 on the output port. Example: The receipt of mapping/resv with the label F1.L1.{0-2} may cause the generation of mapping/resv with the label F3.L2.{4-6}. The result would be that fiber 3 Lambda 2, timeslots 4,5,6 would be mapped to fiber 1, Lambda 1, timeslots 0, 1 and 2 on the output port. Example: The receipt of mapping/resv with the label F1.{L1,L2}.* may cause the generation of mapping/resv with the label F3.{L7,L9}.*. The result would be that fiber 3, Lambdas 7 and 9 would be mapped into fiber 1, Lambdas 1 and 2 respectively on the output port. There are numerous other combinations, limited only by the electro- optical transformations that can be done by any specific switch. Example: The receipt of a mapping/resv with the label F1.L1.{0-47,48-95,96-143,144-191} may cause the generation of a mapping/resv with the label {F2.L4.0-47, F2.L5.0-47, F2.L6.0-47, F2.L7.0-47}. The result is that 48 timeslots on four Lambdas 4,5,6 Fan et al. Expires September 2000 6 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 and 7 on fiber 2, would be mapped into all 192 timeslots on the output fiber 1, on Lambda 1. The inverse of this example is also possible. So a composite label with 4 Lambdas and timeslots when received, may result in the generation of a single Lambda and timeslot set. This represents an inverse multiplexing capability by the switch being traversed. The Appendix of this document shows some examples of the actual formats for some different ASCII representations of composite labels. 3. Extensions to CR-LDP 3.1 Messages and TLVs that are affected by the extensions Any messages, TLVs, and procedures not defined explicitly in this document are defined in [LDP] or [CR-LDP]. The following subsections serve as a cross-reference to [LDP] and [CR-LDP] and as an indication of additional functionality beyond what is defined in [LDP] and [CR-LDP]. "Optional" in the following text is relative to [LDP] or [CR-LDP]. The TLV has to be used if specified here. 3.1.1 Initialization Message The Initialization message is as defined in Section 3.5.3 of [LDP] and is exchanged during LDP peer session initialization to agree upon the common set of parameters to be used when setting up LSPs. The message is used by OLSRs during the initialization with the following extensions: - The Optical Session Parameters TLV must be used as an optional TLV - The procedures to handle Initialization message are augmented by the procedures for processing of the Optical Session Parameters TLV as defined in Section 4 3.1.2 Label Request Message The Label Request message is as defined in Section 3.5.8 of [LDP] and Section 3.2 of [CR-LDP] and used for setting up OLSPs with the following extensions: - The OIT TLV must be used as an optional TLV - The OTD TLV must be used as an optional TLV - Lambda Set TLV is an optional TLV - The procedures to handle the Label Request message are augmented by the procedures for processing of the OIT, OTD and Lambda Set TLVs as defined in Section 5 3.1.3 Label Mapping Message Fan et al. Expires September 2000 7 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 The Label Mapping message is as defined in Section 3.5.7 of [LDP] and Section 3.3 of [CR-LDP] and used for setting up OLSPs with the following extensions: - The Optical Label TLV must be used as the Label TLV. - The Label Mapping procedures are limited to downstream on demand ordered control mode with conservative label retention mode. - The procedures to handle the Label Mapping message are augmented by the procedures for processing of the Optical Label TLV as defined in Section 5. 3.1.4 Notification Message The Notification message is as defined in Section 3.5.1 of [LDP] and Section 3.3 of [CR-LDP]. The Status TLV encoding is as defined in Section 3.4.7 of [LDP]. New status codes are defined in Section 5.6 to signal error notifications associated with the establishment of an OLSP and the processing of the Optical-TLVs. The Notification message may also carry an OIT or OTD TLV. When the OUNI check or compatibility check fails, the ingress OLSR can updates its database correctly by taking into account the actual OUNI type or the link attributes contained in the OIT or OTD TLV. 3.1.5 Release, Withdraw and Abort Messages The Label Release, Label Withdraw and Label Abort messages are used as specified in [LDP] to clear OLSPs. These messages may also carry the Optical Label TLV. 3.2 Optical TLV extensions The messages defined in [LDP] and [CR-LDP] optionally carry one or more of the optional Optical TLVs defined in this section. In this specification, the following TLVs are defined: - Optical Session Parameters TLV - Optical Interface Type TLV - Optical Trail Descriptor TLV - Optical Label TLV - Lambda Set TLV 3.2.1 Optical Session Parameters TLV The Optical Session Parameters TLV is used when an LDP session manages label exchange for Optical Link to specify Optics-specific session parameters. Fan et al. Expires September 2000 8 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Optical Sess Parms | Length | | | | (0x0503) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M | N | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Label Range Component 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Label Range Component 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Label Range Component N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M is a 3-bit field that specifies the Multiplexing Capabilities of an OLSR. The following values are supported in this version: Value Meaning ----- ---------------------------------- 0 Multiplexing not supported 1 SONET/SDH multiplexing supported 2 others (e.g., GE multiplexing supported) N is a 4-bit field that specifies the number of optical label range components. The encoding for an Optical Label Range Component is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Lambda ID | Minimum Lambda ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fiber ID is a 16-bit field that identifies one fiber. Maximum Lambda ID is a 16-bit field that specifies the lower bound of a block of Lambdas that are supported by the originating OLSR. Minimum Lambda ID is a 16-bit field that specifies the lower bound of a block of Lambdas that are supported by the originating OLSR. 3.2.2 Optical Interface Type TLV Fan et al. Expires September 2000 9 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 The OIT TLV is used to represent the traffic characteristics of a User-Network interface. It is carried by Request message. The OIT TLV encoding is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|1| Optical Interface Type | Length | | | | (0x0910) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit refers to Unknown TLV bit as defined in [LDP]. Length specifies the length of the value field in bytes. 3.2.2.1 Service Type Mask 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Type ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Type ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Type ID n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length specifies the length of the value field in bytes. Service Type ID identifies each service type by a unique 32-bit number. The following numbers are defined in this version: Service Type ID Description --------- ------------- 0 IP 1 ATM 2 Frame Relay 3 SONET 4 GE 5 FDDI Fan et al. Expires September 2000 10 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 3.2.2.2 Control Protocol Mask 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Protocol ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Protocol ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Protocol ID n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length specifies the length of the value field in bytes. Control Protocol identifies each control protocol by a unique 32-bit number. The following numbers are defined in this version: Protocol Type ID Description --------- ------------- 0 OSPF 1 RIP 2 BGP4 3 EGP 4 MOSPF 5 DVMRP 6 PIM 7 IS-IS 8 PNNI 3.2.3 Optical Trail Descriptor TLV The OTD TLV represents the characteristics of an optical trail. The optical trail may consist of one or more channel groups of different granularity. All members within a group must have the same granularity, but different group types may be mixed into one OTD TLV. OTD TLV is carried by Request message and its encoding is as follows: Fan et al. Expires September 2000 11 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Optical Trail Desc | Length | | | | (0x0920) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Group 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Group 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Group n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length specifies the length of the value field in bytes. Channel Group describes the components of an optical trail. The encoding of the Channel Group is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Group Type | Number of Group Members | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Channel Group Type defined in this version is as follows: Channel Group Type Description --------- ------------- 1 Fiber 2 Lambda 3 GE 4 10 GE 5 OC-3/STM-1 6 OC-3c 7 OC-12/STM-4 8 OC-12c 9 OC-48/STM16 10 OC-48c 11 OC-192/STM-64 12 OC-192c 13 OC-768/STM-256 14 OC-768c Fan et al. Expires September 2000 12 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 Number of Group Members specifies the number of members within the group. 3.2.4 Optical Label TLV Optical Label TLVs encode optical labels. A simple composite optical Label, noted as F.L.S, is described in 2.4 and is encoded here. The multiple F.L.S can be used to compose an optical Label representing one or more channel groups of different granularity. Optical Label TLVs are carried by the messages used to advertise, request, release and withdraw label mappings. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Optical Label (0x0930) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Component 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Component 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Component n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit refers to Unknown TLV bit as defined in [LDP]. F bit refers to Forward unknown TLV bit as defined in [LDP]. Length specifies the length of the value field in bytes. Label Component encodes F.L.S for a channel group and is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Group Type | Number of Group Members | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Line Rate Encoding Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Channel Group Type is defined in 3.2.3. Number of Group Member is defined in 3.2.3. Line Rate Encoding Type specifies the top encoding protocol. Examples of encoding type include SONET (OC-192, OC-48, etc.) and Fan et al. Expires September 2000 13 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 Ethernet (GE and 10 GE). The type value is the same as channel group type, plus one more, the transparent bit service. The transparent bit service type value is 0. Length specifies the length of field following this field in bytes. Fiber ID is a 16-bit field to specify the fiber. The Lambda ID is a 16-bit field that identifies a Lambda. All the Lambda IDs will be 0x0000 if the group type is fiber. Both Fiber ID and Lambda ID have to be consistent between the two peers. The means to achieve this is out of the scope of this document. Channel Group ID specifies one channel group and is aligned with 4- octet boundary and the format depends on Channel Group Type. The content of the Channel Group ID depends on the channel group type. The Channel Group ID is as follows: 1) For fiber and Lambda group types 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Lambda ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Lambda ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2) For SONET/SDH group type 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Lambda ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The channel ID consists of all STS-1s/STM-1s identified in the bit Mask. The 0 bit in the first 4-octet corresponds to the first STS- 1/STM-1. If group ID bit masks in the last 4-octet are less than 32- bits, it should be left justified in this field and succeeding bits should be set to 0. If the encoding type is OC-192, for example, the group type is OC-48 and the one member in this group, then the Channel ID is 24 bytes long with only 48 bits being set. See appendix A for more details. 3.2.5 Lambda Set TLV Fan et al. Expires September 2000 14 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 Lambda Set TLV represents the set of current available Lambdas. It is useful when trying to setup OLSP through CI-OLSR(s). This TLV is carried by Request message and encoded as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Lambda Set (0x0940) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Lambda ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Lambda ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit refers to Unknown TLV bit as defined in [LDP]. F bit refers to Forward unknown TLV bit as defined in [LDP]. Length specifies the length of the value field in bytes. Lambda ID is defined in 3.2.4. 4. Extensions to RSVP-TE 4.1 Messages and Objects Affected by the Extensions Any messages, objects, and procedures not defined explicitly in this document are defined in the [RSVP] Specifications. The following subsections serve cross-reference to the [RSVP] documents and indicate of additional functionality beyond what is defined in [RSVP]. "Optional" in the following text is relative to [RSVP]. If defined in this specification the TLV has to be used. 4.1.1 Path Message The Path message is as defined in Section 3.1 of [RSVP] and with the following extensions: - The optical label request object must be used as an optional object. - The optical trail descriptor object must be used as an optical object. - The optical interface type object must be used as an optical object. - Lambda object is an optional object. - The procedures to handle the Path message are augmented by the procedures for processing of optical label request, OIT, OTD and Lambda set objects as defined in Section 5. Fan et al. Expires September 2000 15 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 The format of the Path message is as follows: ::= [ ] [ ] [ ] [ ] [ ... ] [ ] ::= [ ] [ ] [ ] 4.1.2 Resv Message The Resv message is as defined in Section 3.2 of [RSVP] and with the following extensions: - The optical label must be used as an optional object. - The procedures to handle the Resv message are augmented by the procedure for the processing of optical label objects as defined in Section 5. The format of Resv message is the same as that in Section 3.2 of [RSVP] except for the replacement the LABEL object with the OPTICAL_LABEL object. 4.1.3 PathErr and ResvErr Messages The PathErr and ResvErr message may also carry optical objects. 4.2 Optical Object Extensions The messages defined in [RSVP] optically carry one or more of the optical objects defined in this section. In this specification, the following optical objects are defined: - OPTICAL_LABEL_REQUEST object - OPTICAL_TRAIL_DESCRIPTOR object - OPTICAL_INTERFACE_TYPE object - OPTICAL_LABEL object - LAMBDA_SET object Fan et al. Expires September 2000 16 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 4.2.1 Optical Label Request Object The OPTICAL_LABEL_REQUEST object is carried in the Path message. 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=19 | C-Type = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | L3PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Label Range Component 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Label Range Component 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Label Range Component n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length specifies the object length in bytes. Reserved is a reserved field. It MUST be set to zero on transmission and MUST be ignored on receipt. L3PID identifies the layer 3 protocol using this path. Standard Ethertype values are used. Optical Label Range Component is defined in Section 3.2.1. 4.2.2 Optical Interface Type This OPTICAL_INTERFACE_TYPE object is carried in the Path message. 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=19 | C-Type = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-objects | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length specifies the object length in bytes. Fan et al. Expires September 2000 17 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 Sub-objects Are Service Type TLV and Control Protocol TLV defined in Section 3.2.2.1 and 3.2.2.2. 4.2.3 Optical Trail Descriptor Object The OPTICAL_TRAIL_DESCRIPTOR object is carried in the Path message. 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=19 | C-Type = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Group 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Group 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Channel Group n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length specifies the object length in bytes. Channel Group is defined in Section 3.2.3. 4.2.4 Optical Label Object This OPTICAL_LABEL object is carried in the Resv message. 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=19 | C-Type = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Component 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Component 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Component n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length specifies the object length in bytes. Label Component is defined in Section 3.2.4. Fan et al. Expires September 2000 18 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 4.2.5 Lambda Set Object This LAMBDA_SET object is carried in the Path message. 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=19 | C-Type = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Lambda ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Lambda ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length specifies the object length in bytes. Lambda ID is defined in Section 3.2.4 5 Processing of Optical TLVs and Optical Objects 5.1 Processing of Optical Session Parameters TLV/Optical Label Request Object A receiving OLSR MUST calculate the intersection between the received range and its own support range. The intersection is the range in which the OLSR may allocate and accept labels. If the intersection of ranges is NULL, the OLSR must send a Notification message with the error code "Session Rejected/Parameters Label Range" in response to the Initialization message and not establish the session in CR-LDP case, or should send a PathErr message with the error code "Routing problem" and the error value "MPLS label allocation failure" in RSVP case. 5.2 Processing of Optical Interface Type TLV/Object When an edge OLSR receives a Request or Path message, it retrieves the OIT field from the message and compares the value of every attribute with that of the requested user-network interface. If all the attributes match, the OIT check is successful. Otherwise, this OLSR generates a Notification or PathErr message to indicate the mismatch. The error code is defined in Section 5.6. For the tandem OLSR, the OIT TLV or Object remains untouched. 5.3 Processing of Optical Trail Descriptor TLV/Object Fan et al. Expires September 2000 19 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 When an OLSR receives a Request or Path message over a SA-link, it retrieves the OTD field from the message and assigns a Label based on the OTD field. When an OLSR sends a Request or Path to next hop over a SA-link, it performs the compatibility check first. The Request or Path message is sent out if the check is successful. Otherwise, this OLSR generates a Notification or PathErr message to indicate the compatibility check failure. The Error code is defined in Section 5.6. The compatibility check must be performed at each SA-link to make sure this link can support the certain type of optical trail as requested. A requested optical trail for example, could be an OC-48 trail and may be built over an OC-192 link. The compatibility check will be successful if this link can support OC-48 multiplexing and an OC-48 channel is available. Otherwise, the compatibility check will fail. The label is assigned based on the OTD field when Mapping or Resv message is handled. 5.4 Processing of Optical Label TLV/Object The processing of Optical Label TLV or Object is similar to that of non-optical label TLV or Object. When an OLSR receives an Optical Label TLV or Object from the Mapping or Resv message, the OLSR updates its Label Information Table with the new label and also configures its connection table based on the Label. 5.5 Processing of Lambda Set TLV/Object When a CI-OLSR receives a Request or Path message and checks the existence of Lambda Set TLV or Object. If the Request or Path message contains a Lambda Set TLV or Object, this CI-OLSR calculates the intersection between the received Lambda set and its own available Lambda set, and replace the Lambda Set TLV or Object field by the intersection Lambda set if the intersection is not NULL. Otherwise, this CI-OLSR generates a Notification or PathErr message to indicate NULL intersection. If the Request or Path message doesn't have a Lambda Set TLV or Object, this CI-OLSR adds a Lambda Set TLV or Object with its own available Lambda set. When a CC-OLSR receives a Request or Path message and removes the Lambda Set TLV or Object if there is one. This CC-OLSR can assign a Label for this OLSP only from the Lambda set contained in Lambda Set TLV or Object. 5.6 Error codes In the Optical-TLV and Optical-Object processing described above, certain errors need to be reported as part of the Notification, PathErr or ResvErr Message. This section defines the status codes Fan et al. Expires September 2000 20 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 for the errors described in this specification. At present, these codes are not exhaustive. Status Code Type --------------------------- ------------ Interface OIT Mismatch 0x05000001 Compatibility Check Failure 0x05000002 Bad OIT TLV/Object 0x05000003 Bad OTD TLV/Object 0x05000004 Bad Optical Label TLV/Object 0x05000005 Bad Lambda Set TLV/Object 0x05000006 NULL intersection 0x05000007 6. Security Considerations This draft does not introduce any new security considerations beyond those specified in [LDP], [CR-LDP], and [RSVP]. 7. References [LDP] Andersson, et al, "Label Distribution Protocol Specification," draft-ietf-mpls-ldp-06.txt, Work in progress, October 1999. [CR-LDP] Bilel Jamoussi, "Constraint-Based LSP Setup using LDP," draft-ietf-mpls-cr-ldp-03.txt, Work in progress, September 1999. [RSVP] Awduche, et al, "Extensions to RSVP for LSR Tunnels," draft- ietf-mpls-rsvp-lsp-tunnel-04.txt, Work in progress, September 1999 [Lambda] Awduche, et al, "Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control with Optical Crossconnects," draft- awduche-mpls-te-optical-01.txt, Work in progress, November 1999 [ROUTING] Wang, et al, "Extensions to OSPF/IS-IS for Optical Routing," draft-wang-ospf-isis-lambda-te-routing-00.txt, Work in progress, March 2000 [PAR] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0," AF-RA-0104.000, January 1999 [AOTN] Draft ITU-T Recommendation G.872, "Architecture of Optical Transport Networks," April 1999. [Sigarch] M. Krishnaswamy, et.al., "MPLS Control Plane for Switched Optical Networks", draft-krishmaswamy-mpls-son-00.txt, work in progress, March 2000 Fan et al. Expires September 2000 21 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 [OLXC] Sid Chaudhuri, Gisli Hjalmtysson, Jennifer Yates, "Control of Lightpaths in an Optical Network", draft-chaudhuri-ip-olxc-control- 00.txt, work in progress, February 2000 8. Acknowledgments The authors would like to thank Guoqiang Wang, Loa Andersson, Bilel Jamoussi and Stephen Shew for their comments on the draft. 9. Author's Addresses Yanhe Fan Peter Ashwood-Smith Nortel Networks Nortel Networks PO Box 3511 Station C PO Box 3511 Station C Ottawa, ON, K1Y 4H7 Ottawa, ON, K1Y 4H7 Canada Canada Phone: 613-765-2315 Phone: 613-763-4534 yanhe@nortelnetworks.com petera@nortelnetworks.com Vishal Sharma Ken Owens Tellabs Research Center Tellabs Operations, Inc. One Kendall Square 1106 Fourth Street Bldg. 100, Suite 121 St. Louis, MO 63126 Cambridge, MA 02139 USA USA Ph: 314-918-1579 Ph: 617-577-8760 Ken.Owens@tellabs.com vishal.sharma@tellabs.com Gerald R. (Jerry) Ash Murali Krishnaswamy AT&T Labs Lucent Technologies Room MT E3-3C37 3C-512 200 Laurel Avenue 101 Crawfords Corner Rd. Middletown, NJ 07748 Holmdel NJ 07733 USA USA Phone: 732-420-4578 Voice: +1 732 949 3611 Fax: 732-440-6687 gash@att.com murali@lucent.com Yang Cao M. K. Girish Lucent Technologies SBC Technology Resources, Inc. 21-2A33, 1600 Osgood St 4698 Willow Road, North Andover, MA 01845-1043 Pleasanton, CA 94588 USA USA Phone: +1 978 960 6173 Phone: +1 925 598-1263 Fax: +1 978 960 6329 Fax: +1 925 598-1322 yangcao@lucent.com mgirish@tri.sbc.com Fan et al. Expires September 2000 22 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 Dr. Simon Bernstein Phuc Nguyen Global One Global One 12490 Sunrise Valley Drive 12490 Sunrise Valley Drive Reston, Reston, VA 20196-0001 USA VA 20196-0001 USA Phone: +1 703 689-7109 Phone: +1 703 689-7870 Fax: + 1 703 689-6724 Fax: + 1 703 689-6724 simon.bernstein@globalone.net Phuc.Nguyen@GlobalOne.net Herbert M. Ruck Lihshin Wang Packet Network Services Qwest Communication. NEC America, Inc. 4250 N Fairfax Drive 1525 Walnut Hill Lane Arlington, VA Irving, TX, 75038 USA U.S.A. Phone: 703-363-3986 Tel. 972-518-3590 Lihshin.Wang@qwest.com ruck@asl.dl.nec.com Sunil Ahluwalia Hans Sjostrand Trillium Digital Systems Inc, Ericsson 12100 Wilshire Blvd. #1800 Business Unit Datacom Networks and IP Services Los Angeles, CA 90025 S-126 25 Stockholm, USA Sweden Phone: 310 442 9222 Phone: +46 8 719 9960 sunil@trillium.com hans.sjostrand@etx.ericsson.se Klas Eriksson Heinrich Hummel Utfors AB Siemens AG Svetsarvagen 24 Hofmannstrasse 51 Sweden 81379 Munich, Germany tel: +46 8 52 70 30 05 Tel: +49 89 722 32057 klas.eriksson@utfors.se heinrich.hummel@icn.siemens.de Avri Doria Nokia Telecommunications 3 Burlington Woods Drive, Suite 250,Burlington, MA 01803 Phone: +1 781 359 5131 Mobile: +1 617 678 9402 avri.doria@nokia.com Fan et al. Expires September 2000 23 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 Appendix A This appendix gives more examples of the optical label. 1) F..* This is for an optical trail of a Lambda group with no sub-Lambda groups. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x0930 | 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Lambda ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Lambda ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fan et al. Expires September 2000 24 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 2) F.L. This is for an optical trail of two sub-Lambda groups (one OC-48 group with two members and one OC-12 group with one member). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| 0x0930 | 64 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Lambda ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+- Channel ID 1 +-+-+-+ | | +-+-+-+- . . . +-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber ID | Lambda ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+- Channel ID 2 +-+-+-+ | | +-+-+-+- . . . +-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Channel ID 1 is 192-bits long and with 96 bits being set. The Channel ID 2 is 192-bits long with only 12 bits being set. Each bit represents an STS-1. Fan et al. Expires September 2000 25 Internet Draft draft-fan-mpls-lambda-signaling-00.txt March 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). 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. Fan et al. Expires September 2000 26