Network Working Group Sugang Xu Internet-Draft Hiroaki Harai Intended status: Standards Track NICT Expires: November 2007 Daniel King Aria Networks June 2007 Extensions to GMPLS RSVP-TE for Bidirectional Lightpath with the Same Wavelength draft-xu-rsvpte-bidir-wave-00 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 For bidirectional lightpaths provisioning, in the case of optical nodes that do not support wavelength conversion, it would be necessary to use the same wavelength along the route on each direction. In certain optical network scenarios, the use of the same wavelength on both directions would be advantageous. For instance, some type of ROADMs may add/drop the same wavelength simultaneously. In another case, the users' optical end nodes are equipped with fixed-wavelength transponders. This document describes extensions to RSVP-TE signaling for bidirectional wavelength lightpaths that require the same wavelength on both directions. By using an LSP_ATTRIBUTES object defined in [RFC4420], the extensions enable the new type lightpaths to support the low cost configuration at users' optical end nodes. Xu et al. Expires November 2007 [Page 1] Internet-Draft draft-xu-rsvpte-bidir-wave-00.txt June 2007 Table of Contents 1. Conventions Used in This Document................................2 2. Terminology......................................................2 3. Introduction and Problem Statement...............................3 3.1 Port-remapping Problem..........................................3 3.2 Port-remapping with OXC.........................................6 4. Avoiding Port-remapping Problem..................................7 4.1 Bidirectional Lightpath using Same Wavelength on Both Directions.7 4.2 Inefficient Alternate Solutions.................................7 4.2.1 Unidirectional Lightpaths with the Same Wavelength............7 4.2.2 Upstream Label Set and Label Set..............................7 5. Using LSP_ATTRIBUTES Object......................................8 6. Label Set Object and Bidirectional Lightpath.....................8 6.1 Procedure.......................................................8 7. Backward Compatibility Considerations............................9 8. IANA Considerations .............................................9 9. Security Considerations..........................................9 10. Acknowledgements................................................9 11. Normative References............................................9 12. Authors' Addresses.............................................10 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology The readers are assumed to be familiar with the terminology defined in [RFC3471], [RFC3473] and [RFC4420]. The term "node" in this document, when used in the context of the procedure description in section 6, refers to the GMPLS node which is the signaling controller in the control plane. The term "receiver" in this document indicates a GMPLS node, which receives messages from its GMPLS neighbor nodes. The term "optical transmitter" in this document is a device that has both a laser tuned on certain wavelength and electronic components, which converts electronic signals into optical signals. The term "optical responder" in this document is a device that has both optical and electronic components. It detects optical signals and converts optical signals into electronic signals. The term "optical transponder" in this document is a device that has both an optical transmitter and an optical responder. The term "optical end node" in this document is the end of a wavelength (optical lambdas) lightpath in the data plane. It may be equipped with some optical/electronic devices such as wavelength Xu et al. Expires November 2007 [Page 2] Internet-Draft draft-xu-rsvpte-bidir-wave-00.txt June 2007 multiplexers/demultiplexer (e.g. arrayed wavelength grating (AWG)), optical transponder, etc., which are employed to transmit/terminate the optical signals for data transmission. The term "wavelength-routed network" in this document is a network that consists of transit nodes which may be equipped with wavelength selective switching elements such as reconfigurable optical add/drop multiplexer (ROADM) or optical cross-connect (OXC), and optical end nodes at edges. Wavelength lightpaths between optical end nodes can be established across the network. 3. Introduction and Problem Statement With the Lambda Switch (LSC) support defined in GMPLS [RFC3471] and RSVP-TE signaling [RFC3473], by properly configuring the wavelength selective switching elements such as ROADMs or OXCs at the transit nodes, both unidirectional and bidirectional wavelength (optical lambdas) lightpaths can be established in a wavelength-routed network. To provide high-performance full-duplex transmission links between users' optical end nodes (e.g. computers, switches and routers, which are equipped with the necessary optical transmitters and responders) directly, bidirectional lightpaths should be established between users' optical end nodes. This document considers the various scenarios where bidirectional lightpaths would be required for users' direct full-duplex end-end communications. By using the LSP_ATTRIBUTES object defined in [RFC4420], new extensions to RSVP-TE signaling are introduced. These extensions enable the lightpath to support the required configuration to enable the same wavelength to be used on both directions between the users' optical end nodes. The extensions in this document would be applied to various scenarios. For example, only a specific wavelength among the multiplexed wavelengths could be added/dropped to an optical end node. In another case, some type of ROADMs may add/drop the same wavelength simultaneously. In these cases, using the same wavelength on both directions is a solution. Another problem that takes into account users' convenience, avoiding port-remapping, is stated as follows. 3.1 Port-remapping Problem In the context of CI-incapable [RFC3471] wavelength-routed networks, where the nodes in the networks cannot support wavelength conversion, the same wavelength on each link along a unidirectional lightpath should be reserved. According to the definition in [RFC3471], a bidirectional lightpath can be seen as a pair of unidirectional lightpaths, which are provisioned along the same route simultaneously by the RSVP-TE signaling with Upstream Label and Label Set Objects in the messages [RFC3473]. A previously defined bidirectional lightpath does not necessarily require the same wavelength on both directions. In consequence, the selection of the upstream and downstream labels Xu et al. Expires November 2007 [Page 3] Internet-Draft draft-xu-rsvpte-bidir-wave-00.txt June 2007 are independent. That is to say, when establishing a bidirectional wavelength lightpath, the wavelengths on both directions selected using RSVP-TE may be different. This may result in a wavelength-routed network specific port-remapping problem at both ends of the bidirectional lightpath. This problem occurs in the following situations: (1) Fixed wavelength multiplexer/demultiplexer like AWGs may be employed at each node. Each incoming and outgoing wavelength is with a dedicated fixed port of AWG. For example, wavelength lambda 1 is on port 1, and wavelength lambda 2 is on port 2, and so on. See Fig.3.1.1. +--+ | |---> lambda 1: port 1 -->| |---> lambda 2: port 2 | |---> lambda 3: port 3 +--+ A. AWG Demultiplexer case. +--+ | |<--- lambda 1: port 1 <--| |<--- lambda 2: port 2 | |<--- lambda 3: port 3 +--+ B. AWG Multiplexer case. Fig.3.1.1. The fixed wavelength-port mapping of AWG Multiplexer/Demultiplexer. (2) Compared to a wavelength-tunable optical transponder array, low cost fixed-tuned optical transponder array may be employed at the edge node. In an optical transponder, the optical responder is bound with the transmitter. Each of the optical transmitters and responders are physically connected to one port of AWG or OXC according to the configuration. See Fig.3.1.2. +--+ +----+ | |<---lambda 1---| T1 | <--| |<---lambda 2---| T2 | | |<---lambda 3---| T3 | +--+ +----+ AWG Multiplexer optical transmitter array A. The configuration with the optical transmitters connecting AWG. +--+ +----+ | |---lambda 1--->| R1 | -->| |---lambda 2--->| R2 | | |---lambda 3--->| R3 | +--+ +----+ AWG Demultiplexer optical responder array B. One possible configuration with the optical responders connecting AWG. Xu et al. Expires November 2007 [Page 4] Internet-Draft draft-xu-rsvpte-bidir-wave-00.txt June 2007 +--+ +-----+ +----+ | |--->| |--->| R1 | -->| |--->| OXC |--->| R2 | | |--->| |--->| R3 | +--+ +-----+ +----+ AWG Demultiplexer optical responder array C. One possible configuration with the optical responders connecting OXC. Fig.3.1.2. The fixed optical transmitter/responder- AGW/OXC port mapping at the optical end nodes. Consider a bidirectional lightpath with different wavelengths on two directions. The optical transmitter of which output wavelength is the same as the outgoing-wavelength (say lambda 1) is chosen first for using the lightpath. Then, the optical responder attached to that transmitter should be selected for receiving the incoming wavelength (say lambda 2). The responder generally can receive any of different wavelengths. Therefore, if another bidirectional lightpath is assigned the same outgoing wavelength (lambda 1) but with a different incoming wavelength (say lambda 3), the same transmitter and responder pair is selected. See Fig.3.1.3. +----+ <-lambda 1---| T1 | +----+ A. Optical transmitter T1 sends optical signals on lambda 1. +----+ -lambda 2--->| R1 | +----+ B. Optical responder R1 receives optical signals on lambda 2 for one bidirectional lightpath. +----+ -lambda 3--->| R1 | +----+ C. Optical responder R1 can receive optical signals on lambda 3 for another bidirectional lightpath. Fig.3.1.3. Transmitter sends optical signals on the fixed-tuned wavelength; the responder can receive data on different wavelengths. However, the communication using the transponder and the bidirectional lightpath with different wavelengths will not succeed under the situations (1) and (2) mentioned above. Remember the fixed port mapping that each incoming wavelength is fixed on a unique port of AWG due to the situation (1), and the optical responder is also fixedly connected to a unique port of AWG or OXC due to the situation (2). Conversely, the incoming wavelength may change every lightpath (see lambda 2 and lambda 3 in the above case) for the same outgoing wavelength (lambda 1). The current incoming wavelength (lambda 3) is not on the port of AWG to which the optical responder Xu et al. Expires November 2007 [Page 5] Internet-Draft draft-xu-rsvpte-bidir-wave-00.txt June 2007 connects originally (lambda 2), see Fig. 3.1.4. To connect the optical responder to the proper port on which the incoming wavelength is, even in different outgoing wavelengths, a port-remapping process between the optical responder and AWG ports may be required. +--+ +----+ | |<---lambda 1---| T1 | <--| |<---lambda 2---| T2 | | |<---lambda 3---| T3 | +--+ +----+ AWG Multiplexer A. Optical transmitter T1 sends optical signals on lambda 1. +--+ | |-- +----+ -->| |--lambda2---->| R1 | | |--lambda3-X +----+ +--+ AWG Demultiplexer B. Optical responder R1 cannot receive optical signals on lambda 3 due to the fixed port mapping, in case of that R1 is physically connected to the port 2 of lambda 2 on AWG. Fig. 3.1.4. Port-remapping problem occurs due to the fixed port-mapping between the optical responder and AWG port. 3.2 Port-remapping with OXC The port-remapping capability depends on the system configurations at users' optical end nodes. For example, an OXC may be employed to switch the incoming wavelength from the port of AWG to the port which the optical responder is connected physically, see Fig. 3.2.1. However, equipping users' optical end nodes with OXCs introduces extra costs. There exists a trade-off between port-remapping capability and cost/system complexity. +--+ +-------+ +----+ | |-lambda 1-->| /--|--->| R1 | -->| |-lambda 2-->|---/ |--->| R2 | | |-lambda 3-->| OXC |--->| R3 | +--+ +-------+ +----+ AWG Demultiplexer A. The optical responder R1 can receive the optical signals on lambda 2. +--+ +-------+ +----+ | |-lambda 1-->| /---|--->| R1 | -->| |-lambda 2-->| / |--->| R2 | | |-lambda 3-->|-/ OXC |--->| R3 | +--+ +-------+ +----+ AWG Demultiplexer B. The optical responder R1 can receive the optical signals on lambda 3. Fig.3.2.1. The port-remapping capability provided by OXC. Xu et al. Expires November 2007 [Page 6] Internet-Draft draft-xu-rsvpte-bidir-wave-00.txt June 2007 Users have various types of optical end node configurations to choose from. Some configurations such as those equipped with OXCs might provide flexibility but could be costly and potentially complicated. Equally, while other configurations without OXCs might lack the flexibility they may be inexpensive and easy to use and maintain. 4. Avoiding Port-remapping Problem Which solution will be employed depends on the considerations of the flexibility and cost/complexity trade-off. If users do not have port-remapping capability at optical end nodes, then it is necessary to avoid the port-remapping, and find a feasible approach to provide users full-duplex transmission capability with bidirectional lightpath. 4.1 Bidirectional Lightpath using Same Wavelength on Both Directions A feasible approach is to establish a bidirectional lightpath with the same wavelength on both directions. At the optical end node, fixed-tuned transponder array is connected to the proper ports of AWG according to the wavelength. Optical transmitter and responder pair connecting the selected outgoing and incoming wavelength ports of AWG will be assigned to the bidirectional lightpath. In this document, the bidirectional lightpath with the same wavelength on both directions is introduced as a complementary lightpath type. 4.2 Inefficient Alternate Solutions 4.2.1 Unidirectional Lightpaths with the Same Wavelength Separately establishing two unidirectional lightpaths on different directions using the same wavelength between two optical end nodes might be an approach to support users' full-duplex transmission requirement. The same wavelength requirement could be achieved by sequentially scanning the wavelengths' availability on both directions. Establish one-way lightpath first and verify the availability of the same wavelength on another lightpath. If the wavelength is not available on both directions, release the former unidirectional lightpath, and repeat this process with a next wavelength, until an available wavelength is found on both directions. However, this solution is inefficient because it might be time consuming during the scan process of the wavelength availability verification. 4.2.2 Upstream Label Set and Label Set Another approach is to extent the RSVP-TE signaling by defining an Upstream Label Set object, and to select the common free wavelengths along the upstream and downstream lightpaths. Although it inherits the idea of Upstream Label from traditional bidirectional LSP, it is still not a neat solution and is inefficient. The simplest way is to only define an extension to the processing of Label Set [RFC3473], and leave the other processes untouched. The issues related to this new functionality including an LSP_ATTRIBUTES Xu et al. Expires November 2007 [Page 7] Internet-Draft draft-xu-rsvpte-bidir-wave-00.txt June 2007 object defined in [RFC4420] and the new procedure are described in the following sections. 5. Using LSP_ATTRIBUTES Object To trigger the new functionality at each GMPLS node, it is necessary to notify the receiver the new type lightpath request. One multi-purpose flag/attribute parameter container object called LSP_ATTRIBUTES object and related mechanism defined in [RFC4420] meet this requirement. One bit in Attributes Flags TLV which indicates the new type lightpath, say, the bidirectional same wavelength lightpath will be present in an LSP_ATTRIBUTES object. Please refer to [RFC4420] for detailed descriptions of the Flag and related issues. 6. Label Set Object and Bidirectional Lightpath Considering the system configuration mentioned above, it is needed to add a new function into RSVP-TE to support bidirectional lightpath with same wavelength on both directions. 6.1 Procedure The lightpath setup procedure is described below: (1) Ingress node adds the new type lightpath indication in an LSP_ATTRIBUTES object. It is propagated in the Path message in the same way as that of a Label Set object for downstream; (2) On reception of a Path message containing both the new type lightpath indication in an LSP_ATTRIBUTES object and Label Set object, the receiver checks the local LSP database to see if the Label Set TLVs are acceptable on both directions jointly. If there are acceptable wavelengths, then copy the values of them into new Label Set TLVs, and forward the Path message to the downstream node. Otherwise the Path message will be terminated, and a PathErr message with a "Routing problem/Label Set" indication will be generated; (3) On reception of a Path message containing both such a new type lightpath indication in an LSP_ATTRIBUTES object and an Upstream Label object, the receiver MUST terminate the Path message using a PathErr message with Error Code "Unknown Attributes TLV" and Error Value set to the value of the new type lightpath TLV type code; (4) On reception of a Path message containing both the new type lightpath indication in an LSP_ATTRIBUTES object and Label Set object, the egress node verifies whether the Label Set TLVs are acceptable, if one or more wavelengths are available on both directions, then any one available wavelength could be selected. A Resv message is generated and propagated to upstream node; (5) When a Resv message is received at an intermediate node, if it is a new type lightpath, the intermediate node allocates the label to interfaces on both directions and update internal database for this bidirectional same wavelength lightpath, then configures the local ROADM Xu et al. Expires November 2007 [Page 8] Internet-Draft draft-xu-rsvpte-bidir-wave-00.txt June 2007 or OXC on both directions. Except the procedure related to Label Set object, the other processes will be left untouched. 7. Backward Compatibility Considerations Due to the introduction of new processing on Label Set object, it is required that each node in the lightpath is able to recognize the new type lightpath indication Flag carried by an LSP_ATTRIBUTES object, and deal with the new Label Set operation correctly. It is noted that this new extension is not backward compatible. According to the descriptions in [RFC4420], an LSR that does not recognize a TLV type code carried in this object MUST reject the Path message using a PathErr message with Error Code "Unknown Attributes TLV" and Error Value set to the value of the Attributes Flags TLV type code. An LSR that does not recognize a bit set in the Attributes Flags TLV MUST reject the Path message using a PathErr message with Error Code "Unknown Attributes Bit" and Error Value set to the bit number of the new type lightpath Flag in the Attributes Flags. The reader is referred to the detailed backward compatibility considerations expressed in [RFC4420]. 8. IANA Considerations The actions for IANA are under discussion and will be added to the document in a later draft. 9. Security Considerations This document adds new procedure related only to Label Set object at each node. It does not introduce any new direct security issues, and the reader is referred to the security considerations expressed in [RFC3473] and [RFC4420]. 10. Acknowledgements The authors would like to thank to Adrian Farrel for helpful comments and feedback. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3471] Berger, L. (Ed.), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L. (Ed.), "Generalized Multi-Protocol Label Xu et al. Expires November 2007 [Page 9] Internet-Draft draft-xu-rsvpte-bidir-wave-00.txt June 2007 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4420] A. Farrel, et al., "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) ", RFC 4420, February 2006 12. Authors' Addresses Sugang Xu National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Koganei, Tokyo, 184-8795 Japan Phone: +81 42-327-6927 Email: xsg@nict.go.jp Hiroaki Harai National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Koganei, Tokyo, 184-8795 Japan Phone: +81 42-327-5418 Email: harai@nict.go.jp Daniel King Aria Networks 44/45 Market Place, Chippenham, SN15 3HU, United Kingdom Phone: +44 7790 775187 Email: daniel.king@aria-networks.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has Xu et al. Expires November 2007 [Page 10] Internet-Draft draft-xu-rsvpte-bidir-wave-00.txt June 2007 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgements Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). This document was produced using xml2rfc v1.32pre3 (of http://xml.resource.org/) from a source in RFC-2629 XML format. Xu et al. Expires November 2007 [Page 11]