Network Assigned Upstream-Label
draft-beeram-ccamp-network-assigned-upstream-label-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Vishnu Pavan Beeram , Igor Bryskin | ||
| Last updated | 2014-02-12 | ||
| Replaced by | draft-ietf-ccamp-network-assigned-upstream-label | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-beeram-ccamp-network-assigned-upstream-label-01
CCAMP Working Group Vishnu Pavan Beeram (Ed)
Internet Draft Juniper Networks
Intended status: Standards Track Igor Bryskin (Ed)
ADVA Optical Networking
Expires: August 12, 2014 February 12, 2014
Network Assigned Upstream-Label
draft-beeram-ccamp-network-assigned-upstream-label-01
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 August 12, 2014.
Copyright Notice
Copyright (c) 2014 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 August 12, 2014 [Page 1]
Internet-Draft Network Assigned Upstream Label February 2014
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This document discusses GMPLS RSVP-TE protocol mechanisms that
enable the network to 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 and
needs to rely on the network to pick an appropriate label.
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. Symmetric Labels...............................................3
3. Unassigned Upstream Label......................................3
3.1. Processing Rules..........................................3
3.2. Backwards Compatibility...................................4
4. Use-Case.......................................................4
4.1. Alien-Wavelength Setup....................................4
4.1.1. Initial Setup........................................5
4.1.2. Wavelength Change....................................6
5. Security Considerations........................................6
6. IANA Considerations............................................6
7. Normative References...........................................6
8. Acknowledgments................................................7
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.
However, there are certain scenarios where it is not desirable or
possible for a given node to pick the upstream-label on its own.
This document defines the protocol mechanisms to be used in such
Beeram, et al Expires August 12, 2014 [Page 2]
Internet-Draft Network Assigned Upstream Label February 2014
scenarios. These mechanisms enable a given node to offload the task
of assigning the upstream-label for a given LSP onto the network.
2. Symmetric Labels
As per [RFC3471], the upstream-label and the downstream-label for an
LSP at a given hop need not be the same. The use-case discussed in
this document (Section 4) pertains to Lambda Switch Capable (LSC)
LSPs and it is an undocumented fact that in practice, LSC LSPs
always have symmetric labels at each hop along the path of the LSP.
The protocol mechanisms discussed in this document assume "Label
Symmetry" and are meant to be used only for Bidirectional LSPs that
assign Symmetric Labels at each hop along the path of the LSP.
3. Unassigned Upstream Label
This document proposes the use of a special label value -
"0xFFFFFFFF" - to indicate an Unassigned Label. The presence of this
value in the UPSTREAM_LABEL object of a PATH message indicates that
the upstream-node has not assigned an upstream label on its own and
has requested the downstream-node to provide a label that it can use
in both forward and reverse directions.
3.1. Processing Rules
The Unassigned Upstream Label is used by an upstream-node when it is
not in a position to pick the upstream label on its own. In such a
scenario, the upstream-node sends a PATH message downstream with an
Unassigned Upstream Label and requests the downstream-node to
provide a symmetric label. If the upstream-node desires to make the
downstream-node aware of its limitations with respect to label
selection, it has the option to specify a list of valid labels via
the LABEL_SET object.
In response, the downstream-node picks an appropriate symmetric
label and sends it via the LABEL object in the RESV message. The
upstream-node would then start using this symmetric label for both
directions of the LSP. If the downstream-node cannot pick the
symmetric label, it MUST issue a PATH-ERR message with a "Routing
Problem/Unacceptable Label Value" indication.
The upstream-node will continue to signal the Unassigned Upstream
Label in the PATH message even after it receives an appropriate
symmetric label in the RESV message. This is done to make sure that
Beeram, et al Expires August 12, 2014 [Page 3]
Internet-Draft Network Assigned Upstream Label February 2014
the downstream-node would pick a symmetric label if and when it
needs to change the RESV label at a later point in time.
+----------+ +------------+
---| Upstream |--------------------| Downstream |---
+----------+ +------------+
PATH
Upstream Label (Unassigned)
Label-Set (L1, L2 ... Ln)
------------------->
RESV
Label (Assigned - L2)
<-------------------
Figure 1: Unassigned UPSTREAM_LABEL
3.2. Backwards Compatibility
If the downstream-node is running an older implementation and
doesn't understand the semantics of an Unassigned UPSTREAM LABEL, it
will either (a) reject the special label value and generate an error
or (b) accept it and treat it as a valid label.
If the behavior that is exhibited is (a), then there are obviously
no backwards compatibility concerns. If there is some existing
implementation that exhibits the behavior in (b), then there could
be some potential issues. The use-case discussed in this draft
pertains to LSC LSPs and it is safe to assume that the behavior in
(b) will not be exhibited for such LSPs.
4. Use-Case
4.1. Alien-Wavelength Setup
Consider the network topology depicted in Figure 2. Nodes A and B
are client IP routers that are connected to an optical WDM transport
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.
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. Depending on the
implementation of this multiplexing function, it may not be
Beeram, et al Expires August 12, 2014 [Page 4]
Internet-Draft Network Assigned Upstream Label February 2014
acceptable to have the router send signal into the optical network
unless it is at the appropriate wavelength. In other words, having
the router send signal with a 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.
|
| +---+ /-\
| | | Router ( ) WDM
| +---+ Node \-/ node
|________________________________
+---+ /-\ /-\ /-\ +---+
| A |---------( F )---------( H )---------( I )---------| B |
+---+ \-/ \-/ \-/ +---+
Figure 2: Sample topology
The mechanisms proposed in this document allow for the optical
network to select and communicate the correct wavelength for such
clients.
4.1.1. Initial Setup
+---+ /-\ /-\ +---+
| A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
+---+ \-/ \-/ +---+
PATH
Upstream Label (Unassigned)
--------------------->
-- ~~ -- ~~ -->
PATH
-------------------->
RESV
<--------------------
<-- ~~ -- ~~ --
RESV
Label (Assigned)
<---------------------
Figure 3: Alien Wavelength - Initial Setup
Beeram, et al Expires August 12, 2014 [Page 5]
Internet-Draft Network Assigned Upstream Label February 2014
Steps:
- "Router A" does not have enough information to pick an
appropriate client wavelength. It sends a PATH downstream
requesting the network to assign an appropriate symmetric label
for it to use. Since the client wavelength is unknown, the
laser is off at the ingress client.
- The network receives the PATH, chooses the appropriate
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 appropriate wavelength (received in the
SUGGESTED_LABEL/LABEL_SET of the PATH) and sends out a RESV
upstream.
- The RESV received by the ingress client carries a valid
symmetric label in the LABEL object. "Router A" turns on the
laser and tunes it to the wavelength specified in the network
assigned symmetric LABEL.
4.1.2. Wavelength Change
After the LSP is set up, the network MAY decide to change the
wavelength for the given LSP. This could be for a variety of reasons
- policy reasons, restoration within the core, preemption etc.
In such a scenario, if the ingress client receives a changed label
via the LABEL object in a RESV modify, it MUST retune the laser at
the ingress to the new wavelength. Similarly if the egress client
receives a changed label via SUGGESTED_LABEL/LABEL_SET in a PATH
modify, it MUST retune the laser at the egress to the new
wavelength.
5. Security Considerations
TBD
6. IANA Considerations
TBD
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Beeram, et al Expires August 12, 2014 [Page 6]
Internet-Draft Network Assigned Upstream Label February 2014
[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.
8. Acknowledgments
TBD
Authors' Addresses
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
John Drake
Juniper Networks
Email: jdrake@juniper.net
Gert Grammel
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
Oscar Gonzalez de Dios
Telefonica
Email: ogondio@tid.es
Beeram, et al Expires August 12, 2014 [Page 7]