Internet Draft Network Working Group Dan Guo (Sorrento Networks) Internet Draft Leah Zhang (Sorrento Networks) Expiration Date: Jan 2001 James Fu (Sorrento Networks) Raymond Cheung (Sorrento Networks) Extensions to RSVP-TE for Bi-directional Optical Path Setup draft-sorrento-rsvp-bi-osp-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 [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 made obsolete 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 We propose an extension to RSVP-TE for setting up and maintaining Bi-directional Optical Switched Paths (BOSPs) in optical networks with symmetric traffic patterns. The requirement for wavelength continuity for some types of optical networks with no (or partial) wavelength conversion is also supported. It follows the framework of MPLS and extends the RSVP-TE to support the signaling for the provisioning of BOSPs. We introduce a new c-types for bi-directional LSPs in both Label Request object and Label object. Each LSR (OXC), upon receiving an RESV message for a BOSP, will allocate a pair of labels. One label is for the incoming port from the next hop and the other is for the incoming port from the previous hop. The labels here include fiber ID, wavelength ID and sub-channel ID (if applicable). This extension requires a minimum change to the existing RSVP-TE protocol. It avoids the problem of contention where two OXCs assign the same wavelength on a uni-directional link for two different sessions. This contention arises in both [4] and [5]. As a result, no additional mechanism for contention resolution is needed. 3. Introduction It is desired to provision bi-directional end-to-end optical paths in optical networks operated by carriers and CLECs. This is driven largely by symmetric traffic requirement in the networks. Setting up two uni-directional paths between two end-points as an equivalent of a bi-directional path has the following drawbacks: 1. Two uni-directional paths may follow two different physical (fiber) routes; 2. There is a time gap for setting up two uni-directional paths between two end-points. This may introduce a contention for resources. It is possible that we will get a deadlock. It may have to abort the setup of a bi-directional path because only one uni-directional path is established. 3. Longer setup latency may be needed. The overall framework for this document is the MPLS as applied to optical networks. We take the approach of RSVP-TE for label distribution. This subject has been studied in the earlier works of [4] and [5]. In [4], the approach is to introduce a Label object in the Path message for allocating the label in the direction from the source to the destination. This deviates from the receiver-initiated approach of path setup (i.e., initiated by RESV messages) in the RSVP. In [5], the approach is for RESV messages to allocate two labels for both incoming and outgoing ports. Both approaches must handle the potential race condition that two set-up attempts at the same time may result in a contention for allocating labels. [5] introduces a mechanism for a pair of OXCs to form master-slave pair and specifies that only master (which has a higher IP address) can allocate the label. A similar mechanism involving IP address is also used in [4] to resolve the contention. We introduce a new c-type for bi-directional LSP in both Path messages and Resv messages. When each OXC receives an RESV message, it allocates two labels, one for the incoming link from the next OXC and the other for incoming link from the other direction. The label is referred to the object containing information for fiber, wavelength and sub-channel (if applicable). Because each uni-directional link can be considered to be an incoming link for only one OXC, no OXCs can engage in a contention scenario where two OXCs assign the same wavelength on a uni-directional link for two different sessions. This reduces the complexity of the protocol. Our approach minimizes the change to the original RSVP-TE protocol. Another issue is the wavelength continuity requirement for certain types of optical networks where OXCs provide no (or partial) function of wavelength conversion. As a result, an optical path from the source to destination may have to stick to a wavelength in this type of networks. RSVP-TE need to be extended to support this type of optical path setup. We organize the rest of this document as follows. In Section 4, we define the necessary new c-types for our proposed extension. In Section 5, we discuss the Path message for pair-wise label request. In section 6, we discuss the Resv messages for pair-wise label allocation. We briefly discuss how BOSPs are torn down in section 7. 4. Extensions for Bi-directional OSPs We define a new C_Type for the label request object defined in [3] as follows: Label Request with BOSP Class=19, c_type = 8 (Bi-directional OSP_Tunnel) 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 | Flags | L3PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Port # | Maximum Port # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Wavelength # | Maximum Wavelength # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Subchannel # | Maximum Subchannel # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. Flags (8 bits): 01 Bi-directional OSP without wavelength continuity requirement 02 Bi-directional OSP with wavelength continuity requirement L3PID (16 bits): An identifier of the layer 3 protocol using this path. Standard Ethertype values are used. Minimum Port # (16 bits): This field specifies the lower bound of a a range of port numbers supported on the originating OXC. Maximum Port # (16 bits): This field specifies the upper bound of a range of port numbers supported on the originating OXC. Minimum Wavelength # (16 bits): This field specifies the lower bound of a range of wavelengths supported on the originating OXC. In the case of Bi-directional OSP with wavelength continuity requirement, this field suggests the wavelength that should be used for the data path from the originating OXC to destination OXC. Maximum Wavelength # (16 bits): This field specifies the upper bound of a range of wavelengths supported on the originating OXC. In the case of Bi-directional OSP with wavelength continuity requirement, this field suggests the wavelength that should be used for the reverse data path from the destination OXC to originating OXC. Minumum Subchannel # (16 bits): This field specifies the lower bound of a range of subchannel supported within a single wavelength on the originating OXC. Maximum Subchannel # (16 bits): This field specifies the upper bound of a range of subchannel supported within a single wavelength on the originating OXC. We also add a new C_Types to the Label objects. The LABEL objects have the following format: LABEL class = 16, C_Type = 8 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port ID1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength ID1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-channel ID1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port ID2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength ID2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-channel ID2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. Operation for Pair-wise Label Request We list our assumptions below: a) An ingress OXC is a sender and a receiver of the SAME traffic class. All optical channel are uni-directional. b) At each OXC, there is a table containing the information which spell out how a uni-directional fiber in one direction is paired to another uni-directional fiber in other direction. This table also spells out the adjacency of OXCs and how ports are connected to the neighbors of this OXC. This table will be dynamically updated. A Path Message is initiated by one OXC (called the initiating OXC) and forwarded to the other end (called the responding OXC) of the bi-directional path. We introduce a new c-type to identify a bi- directional label request. Upon receiving a Path message, an OXC will record the bi-directional label request into its Path State Block (PSB). 6. Operation for Pair-wise Label Reservation An RESV Message is initiated by the responding OXC for this bi- directional path. The RESV message will be propagated to the initiating OXC of this bi-directional path. +-----+ +-----+ L +-----+ To | | | | <------- | | To Prev ----| A | L' | B | | C |---- Next OXC | | --------> | | | | OXC +-----+ +-----+ +-----+ Fig. 1 OXC B will allocate labels for two incoming uni-directional links L and L'. An OXC (in Fig 1, OXC B), upon receiving an RESV message, will assign labels for two incoming uni-directional links (L and L'), one going toward the initiating OXC and the other going toward the responding OXC. (An equally valid scheme is to assign two labels for both outgoing uni-directional links of an OXC.) The label allocation is atomic - either both labels are assigned or no label is assigned. This avoids the potential deadlock. The adjacent OXC at the next hop (i.e., OXC C Fig 1) need to be informed about the label allocation for link L. For this purpose, OXC B will send a special RESV-ERROR Message to OXC C for informing the allocation. To ensure proper interpretation of this message, a new error code (Error code 26) is defined. This message is intended for the adjacent node only and should not be propagated further. When the adjacent node receives the RESV-ERROR message with error code 26, it will extract the label assignment. At that point, this OXC can start to program the switch fabric for this connection. We show the messages passing at OXC B in Fig 2. +-----+ +-----+ RESV +-----+ Prev | OXC | |OXC | <------------ |OXC | -----| A | RESV | B | | C |---Next OXC | | <-------- | | ------------> | | OXC +-----+ +-----+ RESV-ERR(26)+-----+ Fig. 2 Messages passing at OXC B. OXC B allocates two labels for links L and L' at Fig 1. Because each uni-directional link serves as an incoming link for only one OXC, it is impossible that two OXCs can engage in a contention where two OXCs assign the same wavelength on a uni-directional link for two different sessions. Thus, the contention problem, as addressed in both [4] and [5], does not arise. We therefore do not need additional mechanism to resolve the contention. This reduces the complexity of extension for setting up bi-directional OSP. The assignment of labels is carried out by the label manager under the consideration of bandwidth constraint and wavelength constraint. Under the constraint of wavelength continuity, the label manager will use the wavelength suggested in the Label Request messages. The OSP in each direction will use the same wavelength from end to end. When no label can be assigned due to resource constraint or other reasons (such as rejected by policy control), an RESV-Err message will be sent and propagated toward the responding OXC. That will trigger the labels allocated to be torn down and cause the session to fail. 7. Operation for Teardown Messages An ResvTear message must delete the reserved labels for both directions (one going forward and the other going backward) and travels towards all OXCs to the initiating OXC. A PathTear message travels towards all OXCs to the responding OXC and deletes the path state, as well as all dependent reservation state, along the way. A PathTear (ResvTear) message may be conceptualized as a reversed- sense Path message (Resv message, respectively). 8. Security Considerations No new security issues are raised in this document. See [1] for a general discussion of security issues for RSVP. 9. References [1] Braden, R., Zhang, L., Berson, S., et al, "Resource ReserVation Protocol -- Version 1 Functional Specification," RFC 2205, September 1997. [2] Awduche, D. O., Rekhter, Y., Drake, J., Coltun, R., "Multi- Protocol Lambda Switching: Combining MPLS Traffic Engineering Control with Optical Crossconnects," Internet Draft, draft- awduche-mpls-te-optical-00.txt, October 1999. [3] Awduche, D. O., Berger, L., Gan, D.-H., Li, T., Swallow, G., Srinivasan, V., "Extensions to RSVP for LSP Tunnels," Internet Draft, draft-ietf-mpls-rsvp-lsp-tunnel-04.txt, September 1999. [4] Lang, J. P., Mitra, K., Drake, J., "Extensions to RSVP for optical networing," Internet Draft, draft-lang-mpls-rsvp-oxc-00.txt, March 2000 [5] Saha, D., Rajagopalan, B., Tang, B., "RSVP Extensions for Signaling Optical Paths," Internet Draft, draft-saha-rsvp-optical-signaling-00.txt, March 2000 10. Acknowledgement The authors would like to thank Frank Barnes for the helpful discussion and encouragement. 11. Authors' Addresses Dan Guo James Fu Sorrento Networks, Inc. Sorrento Networks, Inc. 9990 Mesa Rim 9990 Mesa Rim San Diego, CA 92121 San Diego, CA 92121 Voice: +1 (858) 450-4964 Voice: +1 (858) 450-4924 Email: dguo@sorrentonet.com Email: jfu@sorrentonet.com Leah Zhang Raymond Cheung Sorrento Networks, Inc. Sorrento Networks, Inc. 9990 Mesa Rim 9990 Mesa Rim San Diego, CA 92121 San Diego, CA 92121 Voice: +1 (858) 450-4977 Voice: +1 (858) 450-4952 Email: leahz@sorrentonet.com Email: rcheung@sorrentonet.com Guo et al. Internet Draft 6 Internet Draft draft-sorrento-rsvp-bi-osp-00.txt Jan. 2001