draft-ietf-teas-network-assigned-upstream-label-00.txt   draft-ietf-teas-network-assigned-upstream-label-01.txt 
TEAS Working Group Vishnu Pavan Beeram (Ed) CCAMP Working Group Vishnu Pavan Beeram (Ed)
Internet Draft Juniper Networks Internet Draft Juniper Networks
Intended status: Standards Track Igor Bryskin (Ed) Intended status: Standards Track Igor Bryskin (Ed)
ADVA Optical Networking ADVA Optical Networking
Expires: June 09, 2015 December 09, 2014 Expires: September 05, 2015 March 05, 2015
Network Assigned Upstream-Label Network Assigned Upstream-Label
draft-ietf-teas-network-assigned-upstream-label-00 draft-ietf-teas-network-assigned-upstream-label-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 09, 2015. This Internet-Draft will expire on September 05, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 22 skipping to change at page 6, line 22
the downstream-node would pick a symmetric label if and when it the downstream-node would pick a symmetric label if and when it
needs to change the RESV label at a later point in time. needs to change the RESV label at a later point in time.
+----------+ +------------+ +----------+ +------------+
---| Upstream |--------------------| Downstream |--- ---| Upstream |--------------------| Downstream |---
+----------+ +------------+ +----------+ +------------+
PATH PATH
Upstream Label (Unassigned) Upstream Label (Unassigned)
Label-Set (L1, L2 ... Ln) Label-Set (L1, L2 ... Ln)
-------------------> ------------------->
RESV RESV
Label (Assigned - L2) Label (Assigned - L2)
<------------------- <-------------------
Figure 3: Unassigned UPSTREAM_LABEL Figure 3: Unassigned UPSTREAM_LABEL
5.2. Backwards Compatibility 5.2. Backwards Compatibility
If the downstream-node is running an older implementation (which may If the downstream-node is running an older implementation (which may
be using the "crank-back" approach discussed in Section 3) and be using the "crank-back" approach discussed in Section 3) and
doesn't understand the semantics of an Unassigned UPSTREAM LABEL, it doesn't understand the semantics of an Unassigned UPSTREAM LABEL, it
will either (a) reject the special label value and generate an error will either (a) reject the special label value and generate an error
or (b) accept it and treat it as a valid label. or (b) accept it and treat it as a valid label.
If the behavior that is exhibited is (a), then there are obviously If the behavior that is exhibited is (a), then there are obviously
skipping to change at page 7, line 29 skipping to change at page 7, line 29
RESV RESV
<-------------------- <--------------------
<-- ~~ -- ~~ -- <-- ~~ -- ~~ --
RESV RESV
Label (Assigned) Label (Assigned)
<--------------------- <---------------------
Figure 4: Alien Wavelength - Initial Setup Figure 4: Alien Wavelength - Initial Setup
Steps: Steps:
- "Router A" does not have enough information to pick an - "Router A" does not have enough information to pick an
appropriate client wavelength. It sends a PATH downstream appropriate client wavelength. It sends a PATH downstream
requesting the network to assign an appropriate symmetric label requesting the network to assign an appropriate symmetric label
for it to use. Since the client wavelength is unknown, the for it to use. Since the client wavelength is unknown, the
laser is off at the ingress client. laser is off at the ingress client.
- The network receives the PATH, chooses the appropriate - The network receives the PATH, chooses the appropriate
wavelength values and forwards them in appropriate label fields wavelength values and forwards them in appropriate label fields
to the egress client ("Router B") to the egress client ("Router B")
- "Router B" receives the PATH, turns the laser ON and tunes it - "Router B" receives the PATH, turns the laser ON and tunes it
to the appropriate wavelength (received in the to the appropriate wavelength (received in the
UPSTREAM_LABEL/LABEL_SET of the PATH) and sends out a RESV UPSTREAM_LABEL/LABEL_SET of the PATH) and sends out a RESV
upstream. upstream.
- The RESV received by the ingress client carries a valid - The RESV received by the ingress client carries a valid
symmetric label in the LABEL object. "Router A" turns on the symmetric label in the LABEL object. "Router A" turns on the
laser and tunes it to the wavelength specified in the network laser and tunes it to the wavelength specified in the network
assigned symmetric LABEL. assigned symmetric LABEL.
For cases where the egress-node relies on RSVP signaling to For cases where the egress-node relies on RSVP signaling to
determine exactly when to start using the LSP, this draft recommends determine exactly when to start using the LSP, this draft recommends
integrating the above sequence with any of the existing graceful integrating the above sequence with any of the existing graceful
setup procedures: setup procedures:
- "RESV-CONF" setup procedure (or) - "RESV-CONF" setup procedure (or)
- 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the - 2-step "ADMIN STATUS" based setup procedure ("A" bit set in the
first step; "A" bit cleared when the LSP is ready for use). first step; "A" bit cleared when the LSP is ready for use).
6.2. Wavelength Change 6.2. Wavelength Change
After the LSP is set up, the network MAY decide to change the 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 wavelength for the given LSP. This could be for a variety of reasons
- policy reasons, restoration within the core, preemption etc. - policy reasons, restoration within the core, preemption etc.
In such a scenario, if the ingress client receives a changed label 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 via the LABEL object in a RESV modify, it SHOULD retune the laser at
the ingress to the new wavelength. Similarly if the egress client the ingress to the new wavelength. Similarly if the egress client
receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH
modify, it MUST retune the laser at the egress to the new modify, it SHOULD retune the laser at the egress to the new
wavelength. wavelength.
7. Security Considerations 7. Security Considerations
TBD This document introduces no new security considerations.
8. IANA Considerations 8. IANA Considerations
TBD This document makes no requests for IANA action.
9. Normative References 9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
Signaling Functional Description", RFC 3471, January Signaling Functional Description", RFC 3471, January
2003 2003
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
Signaling Resource Reservation Protocol-Traffic Signaling Resource Reservation Protocol-Traffic
Engineering Extensions", RFC 3473, January 2003. Engineering Extensions", RFC 3473, January 2003.
10. Acknowledgments 10. Acknowledgments
TBD The authors would like to thank Adrian Farrel, Xian Zhang and Chris
Bowers for their inputs.
Authors' Addresses Authors' Addresses
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
John Drake John Drake
Juniper Networks Juniper Networks
Email: jdrake@juniper.net Email: jdrake@juniper.net
skipping to change at line 389 skipping to change at page 9, line 34
ADVA Optical Networking ADVA Optical Networking
Email: pbrzozowski@advaoptical.com Email: pbrzozowski@advaoptical.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica Telefonica
Email: ogondio@tid.es Email: ogondio@tid.es
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
 End of changes. 14 change blocks. 
30 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/