CCAMP Working Group Nobuaki Matsuura Internet Draft Masaru Katayama Document: draft-matsuura-gmpls-rsvp-requirements-01.txt Kohei Shiomoto Expires: December 2002 NTT June 2002 Requirements for using RSVP-TE in GMPLS signaling draft-matsuura-gmpls-rsvp-requirements-01.txt 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. Abstract In Generalized MPLS, a control channel can be separated physically from the data channel. Such a separation brings issues to use of RSVP-TE for signaling. This document defines requirements for using RSVP-TE in GMPLS signaling. 1. Introduction Generalized MPLS extends the two existing signaling protocols defined for MPLS-TE, i.e. RSVP-TE and CR-LDP, for TDM, LSC, and FSC traffic engineering [GMPLS-SIG, GMPLS-LDP, GMPLS-RSVP]. Furthermore, the RSVP-TE specification is the extension of RSVP protocol that is originally designed for resource reservations in IP networks. In original RSVP [RSVP], a signaling is assumed to be in-band. Each RSVP message is sent hop-by-hop between RSVP-capable routers as a ügrawüh IP datagram. The IP addresses of RSVP downstream messages (Path, PathTear and ResvConf) must be set to DestAddress for the session. Also these messages must be sent with Router Alert IP option in their IP headers. Thus, all routers along a route examine received IP packets carrying RSVP downstream messages, but only RSVP-aware routers recognize and process these messages. The delivery of RSVP downstream messages to the session destination is based on IP routing scheme and unaffected by non-RSVP routers on the path. The assumption of in-band signaling is unchanged in RSVP-TE [RSVP-TE]. Therefore the convention referred above is inherited. However, the use of ERO is limited to cases when all routers along the explicit route support RSVP and the ERO. The use of RRO is limited as well. On the contrary, Generalized MPLS handles non-packet-switch- capable interfaces [GMPLS-SIG]. Thus an in-band signaling can not be assured any longer. An RSVP messages may travel out-of- band with respect to an LSPüfs data channel. In 10.2 of [GMPLS- RSVP], it is said that a Path or PathTear message should be addressed directly to an address associated with the control plane of the node, which is known to be adjacent at the data plane, without Router Alert option. Additionally in a case of hierarchical LSPs, [MPLS-HIERARCHY] describes an alternative method that uses IP encapsulation. This document defines requirements for using RSVP-TE in Generalized MPLS considering possible separation of control and data channels. 2. Requirements for RSVP-TE in GMPLS Nevertheless Generalized MPLS formalizes possible separation between control and data channels, it is unlikely that these control channels are realized via completely different service providerüfs networks. It is rather reasonable to consider that: there should be direct connectivity for communication in the control plane, between immediate neighbors, which are connected physically in the date plane. Even if there is no actual wire, there can be a logical connection by means of IP tunnels. Note that the control channel referred in this document is different from the one discussed in [LMP]. Assuming such an existence of one-to-one relationship between a communication channel in the control plane and a physical connection in the data plane, the conventional manner of RSVP messages can be considered still effective. Particularly, it is useful within the condition that a network topology is subject to change. Specifically, setups and teardowns of FA-LSPs in GMPLS make a network topology transitional itself. For the support of ERO, it is even presumable that all the associated nodes in a network support RSVP. Every node on a path examines received IP packets according to the Router Alert option. If a packet has protocol number 46, the router recognizes and processes it as an RSVP packet. The router looks the ERO in the packet, and then determines an appropriate next hop based on its up-to-date understanding of the network topology. In signaling of hierarchical LSPs, an ingress node is supposed to build an ERO that consist of subobjects including ügLSP regionüh nodes for a Path message. Using conventional RSVP manner, an LSR can receive this message, even if ERO subsequence, which includes the LSR is extracted by an upstream node. It gives the LSR a chance to examine the message. Thus, if the LSR can provide a more optimal route, it may pick up and modify the message. Otherwise, if the LSR determines to be a transit for the FA-LSP, it acts like a non-RSVP node. In addition, when a RSVP message is delivered to terminator node directly jumping intended transit nodes, it is even desirable to provide mechanism that can save the signaling session from an error. Security Considerations This document raises no new security concerns. References [GMPLS-SIG] Ashwood-Smith, P. et al, ügGeneralized MPLS - Signaling Functinal Descriptionüh, Internet Draft, draft-ietf-mpls-generalized-signaling-08.txt, April 2002. (work in progress) [GMPLS-LDP] Ashwood-Smith, P. et al, ügGeneralized MPLS signaling - CR-LDP Extensionsüh, Internet Draft, draft-ietf-mpls-generalized-cr-ldp-06.txt, April 2002. (work in progress) [GMPLS-RSVP] Ashwood-Smith, P. et al, ügGeneralized MPLS signaling - RSVP-TE Extensionsüh, Internet Draft, draft-ietf-mpls-generalized-rsvp-te-07.txt, April 2002. (work in progress) [RSVP] Braden, R. Ed. et al, "Resource ReSerVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. [RSVP-TE] Awduche, D. et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [MPLS-HIERARCHY] Kompella, K. et al, ügLSP Hierarchy with Generalized MPLS TEüh, Internet Draft, draft-ietf-mpls-lsp- hierarchy-05.txt, March 2002. (work in progress) [LMP] Lang, J. P. et al, ügLink Management Protocol (LMP)üh, Internet Draft, draft-ietf-ccamp-lmp-03.txt, May 2002. (work in progress) Author's Addresses Nobuaki Matsuura NTT Corporation 3-9-11 Midori, Musashino Tokyo, Japan 180-8585 Phone: +81 422 59 3758 Email: matsuura.nobuaki@lab.ntt.co.jp Masaru Katayama NTT Corporation 3-9-11 Midori, Musashino Tokyo, Japan 180-8585 Phone: +81 422 59 4354 Email: katy@exa.onlab.ntt.co.jp Kohei Shiomoto NTT Corporation 3-9-11 Midori, Musashino Tokyo, Japan 180-8585 Phone: +81 422 59 4402 Email: shiomoto.kohei@lab.ntt.co.jp Internet Draft draft-matsuura-gmpls-rsvp-requirements-01.txt June 2002