draft-ietf-teas-network-assigned-upstream-label-02.txt   draft-ietf-teas-network-assigned-upstream-label-03.txt 
TEAS Working Group Vishnu Pavan Beeram (Ed) TEAS Working Group Xian Zhang (Ed)
Internet Draft Juniper Networks Internet Draft Huawei Technologies
Intended status: Standards Track Intended status: Standards Track Vishnu Pavan Beeram (Ed)
Juniper Networks
Expires: April 19, 2016 October 19, 2015 Expires: January 07, 2017 July 07, 2016
Network Assigned Upstream-Label Network Assigned Upstream-Label
draft-ietf-teas-network-assigned-upstream-label-02 draft-ietf-teas-network-assigned-upstream-label-03
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 33 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 April 19, 2016. This Internet-Draft will expire on January 07, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
This document discusses a GMPLS (Generalized Multi-Protocol Label This document discusses a Generalized Multi-Protocol Label Switching
Switching) RSVP-TE (Resource reSerVation Protocol with Traffic (GMPLS) Resource reSerVation Protocol with Traffic Engineering
Engineering) protocol mechanism that enables the network to assign (RSVP-TE) mechanism that enables the network to assign an upstream
an upstream label for a bidirectional LSP. This is useful in label for a bidirectional LSP. This is useful in scenarios where a
scenarios where a given node does not have sufficient information to given node does not have sufficient information to assign the
assign the correct upstream label on its own and needs to rely on correct upstream label on its own and needs to rely on the
the downstream node to pick an appropriate label. downstream node to pick an appropriate label.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Use-Case: Alien Wavelength Setup...............................3 2. Use-Case: Wavelength Setup for IP over Optical Networks........3
3. The "Crank-Back" Approach......................................3 3. The "Crankback Signaling" Approach.............................4
4. Symmetric Labels...............................................5 4. Symmetric Labels...............................................5
5. Unassigned Upstream Label......................................5 5. Unassigned Upstream Label......................................5
5.1. Processing Rules..........................................5 5.1. Processing Rules..........................................6
5.2. Backwards Compatibility...................................6 5.2. Backwards Compatibility...................................6
6. Applicability..................................................7 6. Applicability..................................................7
6.1. Initial Setup.............................................7 6.1. Initial Setup.............................................7
6.2. Wavelength Change.........................................8 6.2. Wavelength Change.........................................8
7. Security Considerations........................................8 7. Security Considerations........................................8
8. IANA Considerations............................................8 8. IANA Considerations............................................9
9. References.....................................................9 9. References.....................................................9
9.1. Normative References......................................9 9.1. Normative References......................................9
9.2. Informative References....................................9 9.2. Informative References....................................9
10. Acknowledgments...............................................9 10. Acknowledgments...............................................9
Authors' Addresses................................................9
Contributors.....................................................10
1. Introduction 1. Introduction
The GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE The Generalized Multi-Protocol Label Switching (GMPLS) Resource
(Resource reSerVation Protocol with Traffic Engineering) extensions reSerVation Protocol with Traffic Engineering (RSVP-TE) extensions
for setting up a bidirectional LSP are discussed in [RFC3473]. The for setting up a bidirectional LSP are specified in [RFC3473]. The
bidirectional LSP setup is indicated by the presence of an bidirectional LSP setup is indicated by the presence of an
UPSTREAM_LABEL Object in the PATH message. As per the existing setup UPSTREAM_LABEL Object in the PATH message. As per the existing
procedure outlined for a bidirectional LSP, each upstream node must setup procedure outlined for a bidirectional LSP, each upstream node
allocate a valid upstream label on the outgoing interface before must allocate a valid upstream label on the outgoing interface
sending the initial PATH message downstream. However, there are before sending the initial PATH message downstream. However, there
certain scenarios where it is not desirable or possible for a given are certain scenarios where it is not desirable or possible for a
node to pick the upstream label on its own. This document defines given node to pick the upstream label on its own. This document
the protocol mechanism to be used in such scenarios. This mechanism defines the protocol mechanism to be used in such scenarios. This
enables a given node to offload the task of assigning the upstream mechanism enables a given node to offload the task of assigning the
label for a given bidirectional LSP onto the network. upstream label for a given bidirectional LSP onto the network.
2. Use-Case: Alien Wavelength Setup 2. Use-Case: Wavelength Setup for IP over Optical Networks
Consider the network topology depicted in Figure 1. Nodes A and B Consider the network topology depicted in Figure 1. Nodes A and B
are client IP routers that are connected to an optical WDM transport 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 network. F, H and I represent WDM nodes. The transponder sits on
router and is directly connected to the add-drop port on a WDM node. 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 The optical signal originating on "Router A" is tuned to a
particular wavelength. On "WDM-Node F", it gets multiplexed with particular wavelength. On "WDM-Node F", it gets multiplexed with
optical signals at other wavelengths. Depending on the optical signals at other wavelengths. Depending on the
implementation of this multiplexing function, it may not be implementation of this multiplexing function, it may not be
acceptable to have the router send signal into the optical network acceptable to have the router send signal into the optical network
unless it is at the appropriate wavelength. In other words, having unless it is at the appropriate wavelength. In other words, having
the router send signal with a wrong wavelength may adversely impact the router send signal with a wrong wavelength may adversely impact
existing optical trails. If the clients do not have full visibility existing optical trails. If the clients do not have full visibility
into the optical network, they are not in a position to pick the into the optical network, they are not in a position to pick the
correct wavelength up-front. correct wavelength up-front.
| |
| +---+ /-\ | +---+ /-\
| | | Router ( ) WDM | | | Router ( ) WDM
| +---+ Node \-/ node | +---+ Node \-/ node
|________________________________ |________________________________
+---+ /-\ /-\ /-\ +---+ +---+ /-\ /-\ /-\ +---+
| A |---------( F )---------( H )---------( I )---------| B | | A |---------( F )---------( H )---------( I )---------| B |
+---+ \-/ \-/ \-/ +---+ +---+ \-/ \-/ \-/ +---+
Figure 1: Sample Topology Figure 1: Sample Topology
3. The "Crank-Back" Approach 3. The "Crankback Signaling" Approach
There are currently no GMPLS RSVP-TE protocol mechanisms that an There are currently no GMPLS RSVP-TE protocol mechanisms that an
upstream node can use for indicating that it does not know what upstream node can use for indicating that it does not know what
upstream label to use and that it needs the downstream node to pick upstream label to use and that it needs the downstream node to pick
the label on its behalf. the label on its behalf.
The following setup sequence is an attempt to address the above use- The "Crankback Signaling" [RFC4920] approach can be applied to
case using the crank-back approach supported by GMPLS RSVP-TE: address the above use-case as shown in the following setup sequence:
+---+ /-\ /-\ +---+ +---+ /-\ /-\ +---+
| A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
+---+ \-/ \-/ +---+ +---+ \-/ \-/ +---+
PATH PATH
Upstream Label (any available value) Upstream Label (any available value)
---------------------> --------------------->
PATH-ERR PATH-ERR
Routing problem/Unacceptable Label Value Routing problem/Unacceptable Label Value
skipping to change at page 4, line 39 skipping to change at page 4, line 46
Label (Assigned) Label (Assigned)
<--------------------- <---------------------
Figure 2: Setup Sequence - Crank-back Approach Figure 2: Setup Sequence - Crank-back Approach
The above approach does work, but there are a few obvious concerns: The above approach does work, but there are a few obvious concerns:
- Since "Router-A" does not know which upstream label to use, it - Since "Router-A" does not know which upstream label to use, it
picks some random label and signals it without programming its picks some random label and signals it without programming its
data-plane (this is a deviation from the UPSTREAM_LABEL processing data-plane (this is a deviation from the UPSTREAM_LABEL processing
procedures outlined in [RFC3473]). As a result, the outgoing PATH procedures outlined in [RFC3473]). As a result, the outgoing PATH
message has no indication of whether the upstream label has been message has no indication of whether the upstream label has been
installed along the data-path or not. installed along the data-path or not.
- If "Router-A" somehow correctly guesses (by sheer luck) an - Even if "Router-A" somehow correctly guesses an acceptable
acceptable upstream label upfront, the network may end up finding upstream label upfront, the network may end up finding a path
a path which is suboptimal (there could be a different acceptable which is suboptimal (there could be a different acceptable
upstream label which corresponds to a better path in the network) upstream label which corresponds to a better path in the network)
- The "PATH-ERR with Acceptable Label Set" retry approach is usually - The "PATH-ERR with Acceptable Label Set" retry approach is usually
used for exception handling. The above solution uses it for almost used for exception handling. The above solution uses it for
every single setup request (except in the rare scenario where the almost every single setup request (except in the rare scenario
appropriate upstream label is guessed correctly). where the appropriate upstream label is guessed correctly).
- There is an awkward window between the time the network sends out - There is an awkward window between the time the network sends out
the PATH-ERR message (with the ACCEPTABLE_LABEL_SET) and receives the PATH-ERR message (with the ACCEPTABLE_LABEL_SET) and receives
the corresponding PATH message (with the selected UPSTREAM_LABEL); the corresponding PATH message (with the selected UPSTREAM_LABEL);
this window opens up the possibility of the selected this window opens up the possibility of the selected
UPSTREAM_LABEL to be stale by the time the network receives the UPSTREAM_LABEL to be stale by the time the network receives the
retry PATH. retry PATH.
- The above solution assumes the use of "symmetric labels" by - The above solution assumes the use of "symmetric labels" by
default. default.
The rest of the sections in this draft present a solution proposal The rest of the sections in this draft present a solution proposal
that is devoid of any of the above concerns. that is devoid of any of the above concerns.
4. Symmetric Labels 4. Symmetric Labels
As per [RFC3471], the upstream label and the downstream label for an 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 LSP at a given hop need not be the same. The use-case discussed in
this document pertains to Lambda Switch Capable (LSC) LSPs and it is this document pertains to Lambda Switch Capable (LSC) LSPs and it is
an undocumented fact that in practice, LSC LSPs always have an undocumented fact that in practice, LSC LSPs always have
symmetric labels at each hop along the path of the LSP. symmetric labels at each hop along the path of the LSP.
The use of the protocol mechanism discussed in this document The use of the protocol mechanism discussed in this document
mandates "Label Symmetry". This mechanism is meant to be used only mandates "Label Symmetry". This mechanism is meant to be used only
for bidirectional LSPs that assign symmetric labels at each hop for bidirectional LSPs that assign symmetric labels at each hop
along the path of the LSP. along the path of the LSP.
5. Unassigned Upstream Label 5. Unassigned Upstream Label
This document proposes the use of a special label value - This document proposes the use of a special label value -
"0xFFFFFFFF" - to indicate an Unassigned Upstream Label. The "0xFFFFFFFF" (for a 4-byte label) - to indicate an Unassigned
presence of this value in the UPSTREAM_LABEL object of a PATH Upstream Label. Similar "all-ones" patterns are expected to be used
message indicates that the upstream node has not assigned an for labels of other sizes. The presence of this value in the
upstream label on its own and has requested the downstream node to UPSTREAM_LABEL object of a PATH message indicates that the upstream
provide a label that it can use in both forward and reverse node has not assigned an upstream label on its own and has requested
directions. The presence of this value in the UPSTREAM_LABEL object the downstream node to provide a label that it can use in both
of a PATH message MUST also be interpreted by the receiving node as forward and reverse directions. The presence of this value in the
a request to mandate "symmetric labels" for the LSP. UPSTREAM_LABEL object of a PATH message MUST also be interpreted by
the receiving node as a request to mandate "symmetric labels" for
the LSP.
5.1. Processing Rules 5.1. Processing Rules
The Unassigned Upstream Label is used by an upstream node when it is 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 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 scenario, the upstream node sends a PATH message downstream with an
Unassigned Upstream Label and requests the downstream node to Unassigned Upstream Label and requests the downstream node to
provide a symmetric label. If the upstream node desires to make the provide a symmetric label. If the upstream node desires to make the
downstream node aware of its limitations with respect to label downstream node aware of its limitations with respect to label
selection, it MUST specify a list of valid labels via the LABEL_SET selection, it MUST specify a list of valid labels via the LABEL_SET
object as specified in [RFC3473]. object as specified in [RFC3473].
In response, the downstream node picks an appropriate symmetric In response, the downstream node picks an appropriate symmetric
label and sends it via the LABEL object in the RESV message. The label and sends it via the LABEL object in the RESV message. The
upstream node would then start using this symmetric label for both upstream node would then start using this symmetric label for both
directions of the LSP. If the downstream node cannot pick the directions of the LSP. If the downstream node cannot pick the
symmetric label, it MUST issue a PATH-ERR message with a "Routing symmetric label, it MUST issue a PATH-ERR message with a "Routing
Problem/Unacceptable Label Value" indication. Problem/Unacceptable Label Value" indication.
The upstream node will continue to signal the Unassigned Upstream The upstream node will continue to signal the Unassigned Upstream
Label in the PATH message even after it receives an appropriate Label in the PATH message even after it receives an appropriate
symmetric label in the RESV message. This is done to make sure that symmetric label in the RESV message. This is done to make sure that
the downstream node would pick a different symmetric label if and the downstream node would pick a different symmetric label if and
when it needs to change the label at a later point in time. when it needs to change the 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)
skipping to change at page 6, line 43 skipping to change at page 7, line 7
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 and If the downstream node is running an older implementation 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
as specified in Section 3.1 of [RFC3473] or (b) accept it and treat as specified in Section 3.1 of [RFC3473] or (b) accept it and treat
it as a valid label. 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
no backwards compatibility concerns. If there is some existing no backwards compatibility concerns. If there is some existing
implementation that exhibits the behavior in (b), then there could implementation that exhibits the behavior in (b), then there could
be some potential issues. However, at the time of publication, there be some potential issues. However, at the time of publication,
is no documented evidence of any existing implementation that uses there is no documented evidence of any existing implementation that
0xFFFFFFFF as a valid label. Thus, it is safe to assume that the uses the "all-ones" bit pattern as a valid label. Thus, it is safe
behavior in (b) will never be exhibited. to assume that the behavior in (b) will never be exhibited.
6. Applicability 6. Applicability
The use-case discussed in Section 2 is revisited to examine how the The use-case discussed in Section 2 is revisited to examine how the
mechanism proposed in this document allows the optical network to mechanism proposed in this document allows the optical network to
select and communicate the correct wavelength to its clients. select and communicate the correct wavelength to its clients.
6.1. Initial Setup 6.1. Initial Setup
+---+ /-\ /-\ +---+ +---+ /-\ /-\ +---+
| A |----------------( F ) ~~~~~~~~~ ( I )----------------| B | | A |----------------( F ) ~~~~~~~~~ ( I )----------------| B |
+---+ \-/ \-/ +---+ +---+ \-/ \-/ +---+
PATH PATH
Upstream Label (Unassigned/0xFFFFFFFF) Upstream Label (Unassigned/0xFFFFFFFF)
---------------------> --------------------->
-- ~~ -- ~~ --> -- ~~ -- ~~ -->
PATH PATH
--------------------> -------------------->
RESV RESV
<-------------------- <--------------------
<-- ~~ -- ~~ -- <-- ~~ -- ~~ --
RESV RESV
Label (Assigned) Label (Assigned)
<--------------------- <---------------------
Figure 4: Alien Wavelength - Initial Setup Figure 4: Initial Setup Sequence
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 message appropriate client wavelength. It sends a PATH message
downstream requesting the network to assign an appropriate downstream requesting the network to assign an appropriate
symmetric label for its use. Since the client wavelength is symmetric label for its use. Since the client wavelength is
unknown, the laser is off at the ingress client. unknown, the laser is off at the ingress client.
- The downstream node (Node F) receives the PATH message, chooses - The downstream node (Node F) receives the PATH message, chooses
the appropriate wavelength values and forwards them in the appropriate wavelength values and forwards them in
appropriate label fields to the egress client ("Router B") appropriate label fields to the egress client ("Router B")
- "Router B" receives the PATH message, turns the laser ON and - "Router B" receives the PATH message, turns the laser ON and
tunes it to the appropriate wavelength (received in the tunes it 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
message upstream. message upstream.
- The RESV message received by the ingress client carries a valid
- The RESV message 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
- policy reasons, restoration within the core, preemption etc. reasons - 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 MUST 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 MUST retune the laser at the egress to the new
wavelength. If the node receiving the changed label in a PATH/RESV wavelength. If the node receiving the changed label in a PATH/RESV
message does not find the label acceptable, then the corresponding message does not find the label acceptable, then the corresponding
error procedures defined in [RFC3473] MUST be followed. error procedures defined in [RFC3473] MUST be followed.
7. Security Considerations 7. Security Considerations
This document defines a special label value to be carried in the This document defines a special label value to be carried in the
UPSTREAM_LABEL object of a PATH message. This special label value is UPSTREAM_LABEL object of a PATH message. This special label value
used to enable the function of requesting network assignment of an is used to enable the function of requesting network assignment of
upstream label. The changes proposed in this document pertain to the an upstream label. The changes proposed in this document pertain to
semantics of a specific field in an existing RSVP object and the the semantics of a specific field in an existing RSVP object and the
corresponding procedures. Thus, there are no new security corresponding procedures. Thus, there are no new security
implications raised by this document. implications raised by this document and the security considerations
put together by [RFC3473] still applies.
For a general discussion on MPLS and GMPLS related security issues, For a general discussion on MPLS and GMPLS related security issues,
see the MPLS/GMPLS security framework [RFC5920]. see the MPLS/GMPLS security framework [RFC5920].
8. IANA Considerations 8. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
9. References 9. References
9.1. Normative References 9.1. 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.
skipping to change at page 9, line 20 skipping to change at page 9, line 28
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.
[RFC4920] Farrel, A., "Crankback Signaling Extensions for MPLS
and GMPLS RSVP-TE", RFC 4920, July 2007.
9.2. Informative References 9.2. Informative References
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Adrian Farrel and Chris Bowers for The authors would like to thank Adrian Farrel and Chris Bowers for
their inputs. their inputs.
Authors' Addresses Authors' Addresses
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
Igor Bryskin
Huawei Technologies
Email: igor.bryskin@huawei.com
Daniele Ceccarelli
Ericsson
Email: daniele.ceccarelli@ericsson.com
Oscar Gonzalez de Dios
Telefonica
Email: ogondio@tid.es
Contributors
John Drake John Drake
Juniper Networks Juniper Networks
Email: jdrake@juniper.net Email: jdrake@juniper.net
Gert Grammel Gert Grammel
Juniper Networks Juniper Networks
Email: ggrammel@juniper.net Email: ggrammel@juniper.net
Igor Bryskin
ADVA Optical Networking
Email: ibryskin@advaoptical.com
Pawel Brzozowski Pawel Brzozowski
ADVA Optical Networking ADVA Optical Networking
Email: pbrzozowski@advaoptical.com Email: pbrzozowski@advaoptical.com
Daniele Ceccarelli
Ericsson
Email: daniele.ceccarelli@ericsson.com
Oscar Gonzalez de Dios
Telefonica
Email: ogondio@tid.es
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
Email: zali@cisco.com Email: zali@cisco.com
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
 End of changes. 53 change blocks. 
101 lines changed or deleted 115 lines changed or added

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