CCAMP Working Group Eiji Oki Internet Draft Nobuaki Matsuura Expiration Date: December 2002 Kohei Shiomoto Naoaki Yamanaka NTT Alan Kullberg Netplane Systems Emmanuel Dotaro Dimitri Papadimitriou Martin Vigoureux Alcatel June 2002 Upstream Label Set Support in RSVP-TE extensions draft-oki-ccamp-upstream-labelset-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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes extensions to GMPLS RSVP-TE signaling required to support a upstream label set when a bidirectional path is set up. In Oki et al. [Page 1] Oki et al. draft-oki-ccamp-upstream-labelset-00.txt June 2002 the existing drafts on GMPLS RSVP-TE signaling, a upstream label for the upstream path has to be reserved at an intermediate node before Path message is transmitted to the next-hop node. On the other hand, a label set that includes one or more labels for the downstream path is carried by Path message and then Resv message reserves a label at each interme- diate node on the route or a source node. This document proposes the way to support the upstream label set as is the case of the Label Set for downstream. 1. Introduction RSVP-TE signaling for Generalized MPLS (GMPLS) networks is described [GMPLS-RSVP][GMPLS-SIG]. GMPLS RSVP-TE added a Label Set to MPLS RSVP-TE [RFC3209]. The Label Set is used to limit the label choices of a down- stream node to a set of acceptable labels. This limitation applies on a per hop basis. The Label Set that includes one or more labels for a downstream path is carried by the Path message. It is useful in the optical domain. For example, the Label Set is used when there is a sequence of interfaces which cannot support wavelength conversion (CI-incapable) and require the same wavelength be used end-to-end over a sequence of hops, or even an entire path. The Label Set gives one or more than one option so that a node that receives a Resv message can select one label by considering its own wavelength conversion capability. In the existing drafts on GMPLS RSVP-TE signaling [GMPLS-RSVP][GMPLS- SIG], a label for the upstream path is reserved at an intermediate node before a Path message is transmitted to the next-hop node. As a result, when an intermediate node cannot support wavelength conversion, there is a high possibility that the allocated upstream label at the previous RSVP-hop node can not be accepted at the intermediate node [GMPLS-HPN]. To solve the problem, this document proposes the way to support the upstream label set as is the case of the Label Set for downstream. 2. Upstream Label Set for Bidirectional LSPs 2.1. Upstream Label Set object Upstream Label Set object uses Class-Number TBA (of form 0bbbbbbb) and the C-Type of 2. It is used in Path massage. The format of a Label Set is: 0 1 2 3 Oki et al. [Page 2] Oki et al. draft-oki-ccamp-upstream-labelset-00.txt June 2002 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(TBA)| C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Reserved | Label Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel 1 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subchannel N | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label Type: 14 bits Indicates the type and format of the labels carried in the object. Values match the C-Type of the appropriate Label object. Only the low order 8 bits are used in this field. See [GMPLS-SIG] for a description of other parameters. 2.2. Acceptable Upstream Label Set object Acceptable Upstream Label Set objects use a Class-Number TBA (of form 10bbbbbb). The remaining contents of the object, including C-Type, have the identical format as the Upstream Label Set object. Acceptable Upstream Label Set objects may be carried in a PathErr mes- sage. The procedures for defining an Acceptable Upstream Label Set fol- low the procedures for defining a Upstream Label Set. Specifically, an Acceptable Upstream Label Set is defined via one or more Acceptable Upstream Label Set objects. Specific labels/subchannels can be added to or excluded from an Acceptable Upstream Label Set via Action zero (0) and one (1) objects respectively. Ranges of labels/subchannels can be added to or excluded from an Acceptable Upstream Label Set via Action two (2) and three (3) objects respectively. When the Acceptable Upstream Label Set objects only list labels/subchannels to exclude, this implies that all other labels are acceptable. The inclusion of Acceptable Upstream Label Set objects is optional. If included, the PathErr or ResvErr message SHOULD contain a "Routing prob- lem/Unacceptable upstream label value" indication. The absence of Acceptable Upstream Label Set objects does not have any specific mean- ing. Oki et al. [Page 3] Oki et al. draft-oki-ccamp-upstream-labelset-00.txt June 2002 2.3. Procedure A bidirectional LSP setup is indicated by the presence of either an Upstream Label Object or an Upstream Label Set Object in the Path mes- sage. Both objects are optional. An Upstream Label Object and an Upstream Label Set Object can be co-exit in the Path message. When a Path message containing an Upstream_Label object without an Upstream Label Set object is received, the procedure completely follows [GMPLS-RSVP]. When a Path message containing both an Upstream Label object and an Upstream Label Set object is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST NOT issue a PathErr message with a "Routing problem/Unac- ceptable label value" indication. This is because the Path message includes an Upstream Label Set Object. The receiver second verifies the Upstream Label Set Object. If the node is unable to pick a label from the upstream Label Set or if there is a problem parsing the upstream Label Set Objects, then the request is terminated and a PathErr message with a "Routing problem/Upstream Label Set" indication, which is newly defined, MUST be generated. The generated PathErr message MAY include an Acceptable Upstream Label Set. Whether the upstream label is accept- able or not, the Upstream Label Set Object is propagated in the Path message in the same way as a Label Set for downstream, as long as the Upstream Label Set Object is acceptable at each intermediate node. When an Upstream Label Object is to be included in an outgoing Path mes- sage, whether or not an Upstream Label Set Object is also included, the internal data path must be enabled before sending the PATH message. This is consistent with [GMPLS-RSVP]. Note that, when the established upstream data path by the Path message is not available on the route, the Resv message re-establishes the upstream date path again, as will be described in Section 3. When an Upstream Label in the Upstream Label Object is not available and the option that uses an Upstream Label Set Object is adopted, a Path message includes only an Upstream Label Set Object. In this case, an intermediate node should not allocate a upstream label on the outgoing interface and should not establish internal data paths. When a Resv message is received at an intermediate node, the intermediate node must allocate an upstream label on the outgoing interface and must establish internal data paths. If a Path message contains both an Upstream Label Object and an Upstream Label Set Object, the destination/egress node processes the Path message in the same way as [GMPLS-RSVP]. In this case, the Upstream Label Set Object is ignored. Then, the upstream label can immediately be used to Oki et al. [Page 4] Oki et al. draft-oki-ccamp-upstream-labelset-00.txt June 2002 transport data traffic associated with the LSP upstream towards the ini- tiator, or the source node. When a Path message contains an Upstream Label Set Object without an Upstream Label Object, the destination/egress node selects one Upstream Label from the Upstream Label Set Object and sends the selected label in an Upstream Label Object in the Resv Message towards the upstream direc- tion. A non-refresh Resv message SHOULD include RESV_CONFIRM Object. Note that the necessary condition that a non-refresh Resv message SHOULD include RESV_CONFIRM Object is when the egress node receives a Path mes- sage that contains an Upstream Label Set Object. Contrary to the case that a Path message contains an Upstream Label Object, the selected upstream label MUST NOT be used to transport data traffic associated with the LSP upstream towards the initiator before the destination receive an Upstream Resv Conf Message that indicates that Upstream Labels are allocated and the upstream data path is established on the route. 3. Resv Message An Upstream Label Object can optionally appear in a Resv Message. When an intermediate node processes a Resv message, the Upstream Label propa- gated on the route towards the initiator MUST fall within the Upstream Label Set that was received in the Path message from the upstream peer. Note, on reception of a Resv message, a node that is incapable of per- forming upstream label conversion has no other choice than to use the same physical upstream label (wavelength/band) as received in the Resv message. In this case, the use and propagation of an Upstream Label Set will significantly reduce the chances that this allocation will fail. When a Resv message is received at an intermediate node and the Path message transmitted to the downstream peer did NOT include an Upstream Label, OR the Resv message includes an Upstream Label that does not match the Upstream Label transmitted in the Path message, the upstream data path MUST be established before sending a Resv upstream. Additionally, when a received Resv message includes an Upstream Label and the node is CI-Incapable, then the Upstream Label to be transmitted in the Resv to the upstream peer MAY need to be changed. This is the case when the received Path message includes an Upstream Label that is different from the Upstream Label in the received Resv message. Oki et al. [Page 5] Oki et al. draft-oki-ccamp-upstream-labelset-00.txt June 2002 4. Resv Conf Message When an initiator receives a Resv Message with both of an Upstream Label Object and a Resv Confirm Object, it issues a ResvConf Message that includes the same Upstream Label Object received in the Resv Message to the destination node. When the destination node receives the ResvConf Message, the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator. 5. References [GMPLS-SIG] L. Berger et al., "Generalized MPLS - Signaling Functional Description", draft-ietf-mpls-generalized-signaling-08.txt (work in progress) [GMPLS-RSVP] L. Berger et al., "Generalized MPLS Signaling - RSVP-TE Extensions", draft-ietf-mpls-generalized-rsvp-te-07.txt (work in progress) [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RSVP] "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Sepecification", RFC 2205, September 1997. [GMPLS-HPN] M. Vigoureux et al., "GMPLS Architectural Extensions for (Hybrid) Photonic Networks", draft-vigoureux-ccamp-gmpls-architecture- hpn-00.txt (work in progress) 6. Authors' Addresses Eiji Oki NTT Network Innovation Laboratories Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Email: oki.eiji@lab.ntt.co.jp Nobuaki Matsuura NTT Network Innovation Laboratories 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: matsuura.nobuaki@lab.ntt.co.jp Kohei Shiomoto Oki et al. [Page 6] Oki et al. draft-oki-ccamp-upstream-labelset-00.txt June 2002 NTT Network Innovation Laboratories 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: shiomoto.kohei@lab.ntt.co.jp Naoaki Yamanaka NTT Network Innovation Laboratories 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: yamanaka.naoaki@lab.ntt.co.jp Alan Kullberg NetPlane Systems, Inc. Westwood Executive Center 200 Lowder Brook Drive Westwood, MA 02090 e-mail: akullber@netplane.com Emmanuel Dotaro Alcatel Route de Nozay, 91460 Marcoussis, France Phone: +33 1 6963-4723 Email: emmanuel.dotaro@alcatel.fr Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: dimitri.papadimitriou@alcatel.be Martin Vigoureux Alcatel Route de Nozay, 91460 Marcoussis, France Phone: +33 1 6963-1852 Email: martin.vigoureux@alcatel.fr Oki et al. [Page 7]