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]