Nobuaki Matsuura Internet Draft Masaru Katayama Document: draft-matsuura-gmpls-rsvp-requirements-00.txt Kohei Shiomoto Expiration Date: August 2002 NTT Requirements for using RSVP-TE in GMPLS signaling draft-matsuura-gmpls-rsvp-requirements-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. 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 Current GMPLS signalling based on RSVP-TE doesn't provide support for message forwarding hop-by-hop in the network of which management netwrok is constructed separately from the data channel. This document defines requirements for using RSVP-TE in GMPLS signaling. draft-matsuura-gmpls-rsvp-requirements-00.txt [Page 1] Internet Draft draft-matsuura-gmpls-rsvp-requirements-00.txt February 2002 1. Introduction GMPLS signaling must be capable of transporting the required circuit (LSP) parameters such as the bandwidth, the type of signal, the desired protection and/or restoration, the position in a particular multiplex, etc. Most of these extensions have already been defined for PSC and L2SC traffic engineering with MPLS. GMPLS primarily defines additional extensions for TDM, LSC, and FSC traffic engineering. Thus, GMPLS extends the two signaling protocols defined for MPLS-TE signaling, i.e. RSVP-TE and CR-LDP [GMPLS-ARCH]. However, current GMPLS signalling based on RSVP-TE doesn't provide support for message forwarding hop-by-hop in the network of which management netwrok is constructed separately from the data channel. This document defines requirements for using RSVP-TE in GMPLS signaling. 2. Problem statement Generalized MPLS formalizes possible separation of control and data channels. Such support is particularly important to support technologies where control traffic cannot be sent in-band with the data traffic. In GMPLS, a control channel could use a separate wavelength or fiber, an Ethernet link, or an IP tunnel through a separate management network [LMP]. RSVP is designed to operate correctly through such a non-RSVP cloud. Both RSVP and non-RSVP routers forward Path messages towards the destination address using their local routing table. Therefore, the routing of Path messages will be unaffected by non-RSVP routers in the path. When a Path message traverses a non-RSVP cloud, it carries to the next RSVP-capable node the IP address of the last RSVP-capable router before entering the cloud [RFC 2205]. draft-matsuura-gmpls-rsvp-requirements-00.txt [Page 2] Internet Draft draft-matsuura-gmpls-rsvp-requirements-00.txt February 2002 Assume a GMPLS network shown in Figure 1. Control channel is realized as an IP cloud separated from the data plane. Path message for setup of the LSP from node A to node C is sent to the IP address of node C's control channel. In this case, the Path message is delivered directly to node C through the control channel network and is not received by node B. Thus, LSP cannot be set up. _____________________ | | ______| Control channel |____ | |_________ ___________| | | | | __|__ __|__ __|__ | | | | | | | __|__________|_____|__________|__ | | __|__________|_____|__________|__ | |_____| |_____| LSP |_____| Node A Node B Node C Figure 1 Sample network. 3. Requirements for GMPLS signaling network For the reason mentioned above, control channel in GMPLS network must be deployed corresponding to the data plane topology in order to forward RSVP massage hop-by-hop along the path to be set up. If not, other mechanism that assures hop-by-hop forwarding of RSVP message is needed. draft-matsuura-gmpls-rsvp-requirements-00.txt [Page 3] Internet Draft draft-matsuura-gmpls-rsvp-requirements-00.txt February 2002 4. Security Considerations This document raises no new security concerns for RSVP. References [GMPLS-ARCH] Eric Mannie, et. al. "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", draft-ietf-ccamp-gmpls-architecture-01.txt (work in progress) [LMP] Lang, et al. "Link Management Protocol", draft-ietf-mpls-lmp-02.txt (work in progress) [RFC2205] Braden, R. Ed. et al, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205 draft-matsuura-gmpls-rsvp-requirements-00.txt [Page 4] Internet Draft draft-matsuura-gmpls-rsvp-requirements-00.txt February 2002 Author Information Nobuaki Matsuura NTT Corporation 3-9-11 Midori, Musashino Tokyo, JPN 180-8585 e-mail: matsuura.nobuaki@lab.ntt.co.jp Masaru Katayama NTT Corporation 3-9-11 Midori, Musashino Tokyo, JPN 180-8585 e-mail: katy@exa.onlab.ntt.co.jp Kohei Shiomoto NTT Corporation 3-9-11 Midori, Musashino Tokyo, JPN 180-8585 e-mail: shiomoto.kohei@lab.ntt.co.jp draft-matsuura-gmpls-rsvp-requirements-00.txt [Page 5]