CCAMP Working Group Vishnu Pavan Beeram (Ed)
Internet Draft Juniper Networks
Intended status: Standards Track Igor Bryskin (Ed)
ADVA Optical Networking
Expires: April 20, 2014 October 20, 2013
Network Assigned Upstream-Label
draft-beeram-ccamp-network-assigned-upstream-label-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and 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
This Internet-Draft will expire on April 20, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Beeram, et al Expires April 20, 2014 [Page 1]
Internet-Draft Network Assigned Upstream Label July 2013
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This document discusses the GMPLS RSVP-TE extensions that are needed
to let the network assign an upstream-label for a given LSP. This is
useful in scenarios where a given node does not have sufficient
information to assign the correct upstream-label on its own. This
document also specifies the extensions required for manipulating
Label-Symmetric Bidirectional GMPLS LSPs.
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 RFC-2119 [RFC2119].
Table of Contents
1. Introduction...................................................2
2. Label Symmetricity.............................................3
2.1. Processing Rules..........................................3
3. Unassigned Upstream Label......................................4
3.1. Processing Rules..........................................4
4. Upstream Label Set / Acceptable Upstream Label Set.............5
4.1. Object Formats............................................6
4.2. Processing Rules..........................................6
5. Use-Cases......................................................7
5.1. Alien-Wavelength Setup....................................7
5.1.1. Setup Procedure - Example............................8
6. Security Considerations.......................................10
7. IANA Considerations...........................................11
8. Normative References..........................................11
9. Acknowledgments...............................................11
1. Introduction
The GMPLS RSVP-TE extensions for setting up a Bidirectional LSP are
discussed in [RFC3473]. The Bidirectional LSP setup is indicated by
the presence of an UPSTREAM_LABEL Object in the PATH message. As per
the existing setup procedure outlined for a Bidirectional LSP, each
upstream-node must allocate a valid upstream-label on the outgoing
interface before sending the initial PATH message downstream.
Beeram, et al Expires April 20, 2014 [Page 2]
Internet-Draft Network Assigned Upstream Label July 2013
However, there are certain scenarios (Section 5) where it is not
desirable for a given node to pick the upstream-label on its own.
This document discusses the protocol extensions that are required in
such cases to let the network assign an upstream-label for a given
LSP.
As per [RFC3471], the upstream-label and the downstream-label for an
LSP at a given hop need not be the same. However, most practical
scenarios require these two labels to be the same. This document
proposes a mechanism for the ingress to request "Label Symmetricity"
at each hop of the LSP. It also discusses how the request to have
"Label Symmetricity" gets processed in conjunction with the request
to have "a network assigned upstream-label".
2. Label Symmetricity
In order to request "Label Symmetricity", this document defines a
new flag (Label_Symmetricity Required) in the Attributes Flags TLV
[RFC5420]. The position of this flag in the TLV is TBA.
If the upstream-label and the downstream-label are required to be
the same at each hop of the LSP, then the PATH sent out by the
ingress would have this flag set in the Attributes Flags TLV of the
LSP_REQUIRED_ATTRIBUTES object.
2.1. Processing Rules
The presence of the "Label Symmetricity_Required" flag in the PATH
message indicates that the LSP is bidirectional and that the labels
are symmetric in both directions at each hop. Since this flag gets
carried in the LSP_REQUIRED_ATTRIBUTES object, a downstream node
that does not recognize/support this flag would reject the LSP setup
request (indicating that the requested attributes are not
supported).
When this flag is set in the PATH message, the upstream node may or
may not add the UPSTREAM_LABEL object in the initial setup request
sent to the downstream node. If the UPSTREAM_LABEL does get
specified in the PATH, the downstream nodes MUST ignore it. If the
upstream node desires to pick the symmetric label on its own, it
MUST encode this in the LABEL_SET object and send it downstream.
The downstream-node picks an appropriate symmetric label and sends
this via the LABEL object in the RESV message. The upstream-node
would then start using this symmetric label for both directions of
the LSP.
Beeram, et al Expires April 20, 2014 [Page 3]
Internet-Draft Network Assigned Upstream Label July 2013
+----------+ +------------+
---| Upstream |--------------------| Downstream |---
+----------+ +------------+
PATH
LSP Req Attr (Label Symmetricity)
Label-Set (L)
------------------->
RESV
Label (Assigned - L)
<-------------------
PATH
LSP Req Attr (Label Symmetricity)
Upstream Label (Assigned - L)
------------------->
Figure 1: Label Symmetricity
The remaining extensions discussed in this document are not relevant
for LSPs that require "Label Symmetricity".
3. Unassigned Upstream Label
This document proposes the use of a special label value -
"0xFFFFFFFF" - to indicate an Unassigned Label. This would get used
by a node if it does not have any input on what upstream-label needs
to get picked. This special label is filled in the UPSTREAM_LABEL
object of the PATH message that is sent downstream.
3.1. Processing Rules
In the ideal scenario, the network responds by filling in a valid
UPSTREAM_LABEL in the corresponding RESV message. If the network is
not in a position to assign the UPSTREAM LABEL (or if it doesn't know
what to do with an Unassigned UPSTREAM_LABEL), it MUST issue a PATH-
ERR message with a "Routing Problem/Unacceptable Label Value"
indication. If the RESV comes in without an assigned UPSTREAM_LABEL,
then an error with a "Routing Problem/Label Allocation Failure"
indication MUST be issued.
Beeram, et al Expires April 20, 2014 [Page 4]
Internet-Draft Network Assigned Upstream Label July 2013
+----------+ +------------+
---| Upstream |--------------------| Downstream |---
+----------+ +------------+
PATH
Upstream Label (Unassigned)
------------------->
RESV
Upstream Label (Assigned - L1)
Label (Assigned - L2)
<-------------------
PATH
Upstream Label (Assigned - L1)
------------------->
Figure 2: Unassigned UPSTREAM_LABEL
The above processing rules do not apply if an "Unassigned
UPSTREAM_LABEL" is included in a PATH message that also has the
"Label_Symmetricity_Required" bit set. In that case, the downstream
node would ignore the presence of the "UPSTREAM LABEL" (and the
rules specified in Section 2.1 come into play).
4. Upstream Label Set / Acceptable Upstream Label Set
This document proposes the use of UPSTREAM_LABEL_SET and
ACCEPTABLE_UPSTREAM_LABEL_SET for scenarios where a given node
desires to give the network some choices when picking a valid
UPSTREAM_LABEL. The UPSTREAM_LABEL_SET object is the upstream
equivalent of the LABEL_SET object. The UPSTREAM_LABEL_SET object
carries a list of acceptable upstream labels and gets signaled in
the PATH message that is sent downstream. The network responds by
picking a valid UPSTREAM_LABEL from the given list and signals it
back in the corresponding RESV message.
The ACCEPTABLE_LABEL_SET is currently used to specify both upstream
and downstream label-sets. However, in scenarios where there is no
label symmetricity, it becomes necessary to have constructs that can
specify both an acceptable upstream label-set and an acceptable
downstream label-set at the same time. The
ACCEPTABLE_UPSTREAM_LABEL_SET construct introduced in this document
helps fill that void.
Beeram, et al Expires April 20, 2014 [Page 5]
Internet-Draft Network Assigned Upstream Label July 2013
4.1. Object Formats
The UPSTREAM_LABEL_SET object uses Class-Number TBA (of form
0bbbbbbb) and the C-Type of 1.
The format of UPSTREAM_LABEL_SET:
0 1 2 3
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 (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : |
: : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The parameters are similar to ones defined for LABEL_SET. See
[RFC3471] for their description.
The ACCEPTABLE_UPSTREAM_LABEL_SET object uses class-number TBA (of
form 10bbbbbb) and C-Type 1. The format/parameters of this object
are identical to that of the UPSTREAM_LABEL_SET.
4.2. Processing Rules
The inclusion of the optional UPSTREAM_LABEL_SET object in the PATH
message indicates that the LSP is bidirectional.
In the ideal case, the network picks a valid upstream-label from the
specified list and fills this in the UPSTREAM_LABEL object of the
corresponding RESV message. If the network is not able to pick a
valid upstream-label from the list specified in the
UPSTREAM_LABEL_SET, it MUST generate a PATH-ERR message with a
"Routing Problem/Unacceptable Label value" indication. The PATH-ERR
message may optionally include the ACCEPTABLE_UPSTREAM_LABEL_SET
Beeram, et al Expires April 20, 2014 [Page 6]
Internet-Draft Network Assigned Upstream Label July 2013
object to indicate a list of acceptable labels supported by the
network at that instant.
+----------+ +------------+
---| Upstream |--------------------| Downstream |---
+----------+ +------------+
PATH
Upstream Label Set (L1, L2 ... Ln)
------------------->
RESV
Upstream Label (Assigned - L2)
Label (Assigned - Lx)
<-------------------
PATH
Upstream Label (Assigned - L2)
------------------->
Figure 3: UPSTREAM_LABEL_SET
The UPSTREAM_LABEL object and the UPSTREAM_LABEL_SET object may both
be included in a PATH message. The rules of processing when both
objects are included are as follows:
- If the UPSTREAM_LABEL carries a valid assigned value, then the
UPSTREAM_LABEL_SET object (if present) MUST be ignored.
- If the UPSTREAM LABEL carries an unassigned value, then the
Unassigned UPSTREAM_LABEL MUST be ignored. The UPSTREAM_LABEL_SET
gets processed instead in such cases.
The above processing rules do not apply if an "USPTREAM_LABEL_SET"
is included in a PATH message that also has the
"Label_Symmetricity_Required" bit set. In that case, the downstream
node would ignore the presence of the "UPSTREAM LABEL_SET" (and the
rules specified in Section 2.1 come into play).
5. Use-Cases
5.1. Alien-Wavelength Setup
Consider the network topology depicted in Figure 3. Nodes A and B
are client IP routers that are connected to an optical WDM transport
Beeram, et al Expires April 20, 2014 [Page 7]
Internet-Draft Network Assigned Upstream Label July 2013
network. F, H and I represent WDM nodes. The transponder sits on the
router and is directly connected to the add-drop port on a WDM node.
|
| +---+ /-\
| | | Router ( ) WDM
| +---+ Node \-/ node
|________________________________
+---+ /-\ /-\ /-\ +---+
| A |---------( F )---------( H )---------( I )---------| B |
+---+ \-/ \-/ \-/ +---+
Figure 4: Sample topology
The optical signal originating on "Router A" is tuned to a
particular wavelength. On "WDM-Node F", it gets multiplexed with
optical signals at other wavelengths via an optical-filter.
Depending on the implementation of this multiplexing function, it
may not be acceptable to have the router send signal into the
optical network unless it is at the correct wavelength. In
particular, for some tunable filter implementations, multiplexing of
signals with the same wavelength will result in an unreadable signal
on that wavelength. Hence, having the router send signal with wrong
wavelength may adversely impact existing optical trails. If the
clients do not have full visibility into the optical network, they
are not in a position to pick the correct wavelength up-front. The
mechanisms proposed in this document allow the optical network
specify the correct wavelength for such clients.
5.1.1. Setup Procedure - Example
The following is an illustration of gracefully setting up ([GR-
SETUP]) a Lambda LSP using "Unassigned Upstream Label". "Label
Symmetricity" is not requested for the LSP in this particular
example.
Beeram, et al Expires April 20, 2014 [Page 8]
Internet-Draft Network Assigned Upstream Label July 2013
+---+ /-\ /-\ +---+
| A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
+---+ \-/ \-/ +---+
Step 1:
PATH
Admin Status (A, R)
Upstream Label (Unassigned)
--------------------->
-- ~~ -- ~~ -->
PATH
Admin Status (A, R)
-------------------->
RESV
Admin Status (A)
<--------------------
<-- ~~ -- ~~ --
RESV
Admin Status (A)
Upstream Label (Assigned)
<---------------------
Step 2:
PATH
Admin Status (R),
Upstream Label (Assigned)
--------------------->
-- ~~ -- ~~ -->
PATH
Admin Status (R)
-------------------->
RESV
Admin Status
<--------------------
<-- ~~ -- ~~ --
RESV
Admin Status
Upstream Label (Assigned)
<--------------------
Figure 5: Alien Wavelength Setup
Beeram, et al Expires April 20, 2014 [Page 9]
Internet-Draft Network Assigned Upstream Label July 2013
Step 1:
- "Router A" does not have enough information to pick the correct
client wavelength. It sends a PATH downstream requesting the
network to assign an appropriate UPSTREAM_LABEL for it to use.
As per the graceful setup procedure outlined in [GR-SETUP], the
PATH is sent out with the "A" bit set in the ADMIN_STATUS. This
indicates that the LSP is not operational and that the laser is
turned off at the ingress client.
- The network receives the PATH, chooses the correct wavelength
values and forwards them in appropriate label fields to the
egress client ("Router B")
- "Router B" receives the PATH, turns the laser ON and tunes it
to the correct wavelength (received in the LABEL_SET of the
PATH) and sends out a RESV upstream. The RESV is sent out with
the "A" bit set in the ADMIN_STATUS - indicating that the LSP
is still not operational.
- The RESV received by the ingress client carries a valid
assigned UPSTREAM label. "Router A" turns on the laser and
tunes it to the wavelength specified in the network assigned
UPSTREAM_LABEL. This completes Step-1.
Step 2:
- "Router A" sends out a PATH trigger with the "A" bit cleared in
the ADMIN_STATUS. This indicates the ingress client's desire to
make the LSP operational
- The network receives the PATH, adjusts the power-levels
appropriately (also takes care of any other applicable
provisioning operations) and then forwards the PATH with the
"A" bit cleared to the egress client.
- The egress client sends out a RESV trigger in response with the
"A" bit cleared in the ADMIN_STATUS. From this point on, the
LSP is deemed "ready for use" by the egress client.
- The RESV with the "A" bit cleared in the ADMIN_STATUS makes its
way to the ingress client. From this point on, the LSP is
deemed fully operational by the ingress client.
6. Security Considerations
TBD
Beeram, et al Expires April 20, 2014 [Page 10]
Internet-Draft Network Assigned Upstream Label July 2013
7. IANA Considerations
TBD
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
Signaling Functional Description", RFC 3471, January
2003
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
Signaling Resource Reservation Protocol-Traffic
Engineering Extensions", RFC 3473, January 2003.
[RFC5420] Farrel, A., "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol
Traffic Engineering (RSVP-TE)", RFC5420, February 2009.
[UP-LBL-SET] Oki, E., "Upstream Label Set Support in RSVP-TE
extensions", <draft-oki-ccamp-upstream-labelset>,
June 2002.
[GR-SETUP] Beeram, V., "RSVP Graceful Setup",
<draft-beeram-ccamp-rsvp-graceful-setup>, October 2013
9. Acknowledgments
We would like to acknowledge the authors of <draft-oki-ccamp-
upstream-labelset> for introducing the notion of an
UPSTREAM_LABEL_SET.
Authors' Addresses
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
John Drake
Juniper Networks
Email: jdrake@juniper.net
Gert Grammel
Beeram, et al Expires April 20, 2014 [Page 11]
Internet-Draft Network Assigned Upstream Label July 2013
Juniper Networks
Email: ggrammel@juniper.net
Igor Bryskin
ADVA Optical Networking
Email: ibryskin@advaoptical.com
Pawel Brzozowski
ADVA Optical Networking
Email: pbrzozowski@advaoptical.com
Daniele Ceccarelli
Ericsson
Email: daniele.ceccarelli@ericsson.com
Beeram, et al Expires April 20, 2014 [Page 12]