Internet DRAFT - draft-saad-mpls-lsp-instant-install-rsvpte
draft-saad-mpls-lsp-instant-install-rsvpte
MPLS Working Group T. Saad
Internet-Draft G. Swallow
Intended status: Standards Track Cisco Systems Inc
Expires: April 18, 2016 October 16, 2015
Extensions to RSVP-TE for LSP Instant Install
draft-saad-mpls-lsp-instant-install-rsvpte-00
Abstract
When establishing new RSVP-TE LSPs, it is permissible that LSRs along
the LSP path to forward the RSVP Resv message upstream before
installing the forwarding state. In practise, this is done to
parallelize the forwarding state installation. While the ingress can
start to use the LSP as soon as the RSVP Resv message arrives, doing
so may lead to traffic drops at intermediate LSRs that may not have
completed the installation of forwarding state for the new LSP.
This document describes procedures and provides extensions to RSVP-TE
protocol to allow an ingress LSR to immediately install and forward
traffic on a newly signalled LSP as soon as the RSVP reservation
state is received.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 18, 2016.
Copyright Notice
Copyright (c) 2015 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
Saad & Swallow Expires April 18, 2016 [Page 1]
Internet-Draft RSVP-TE LSP Instant Install October 2015
(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 Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . 4
3.1. TE Data Link Label Collection Indication . . . . . . . . 4
3.2. TE Data Link Label Collection . . . . . . . . . . . . . . 4
3.3. TE Data Link Label Update . . . . . . . . . . . . . . . . 5
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. RRO TE Data Link Label Sub-object . . . . . . . . . . . . 5
5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . 7
5.1. TE Data Link Label Collection . . . . . . . . . . . . . . 7
5.2. TE Data Link Label Update . . . . . . . . . . . . . . . . 9
5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 9
6. Behavior of LSRs for Instant LSP Installation . . . . . . . . 9
6.1. Behavior of Ingress LSR . . . . . . . . . . . . . . . . . 9
6.2. Behavior of All LSRs . . . . . . . . . . . . . . . . . . 10
7. Manageability Considerations . . . . . . . . . . . . . . . . 10
7.1. Policy Configuration . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . 11
9.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 11
9.3. Policy Control Failure Error subcodes . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
The RSVP-TE specification [RFC3209] describes a "make-before-break"
mechanism to meet a traffic engineering requirement to reroute
established TE tunnels without causing disruption to transported
traffic or major impact to network operations. Such a mechanism
necessitates the signaling and establishment of a new LSP tunnel and
transferring traffic from the old LSP tunnel onto it before tearing
down the old LSP tunnel. Using RSVP-TE, the new LSP is signaled in
the network, resulting in reservations in the control plane and a new
Saad & Swallow Expires April 18, 2016 [Page 2]
Internet-Draft RSVP-TE LSP Instant Install October 2015
state in forwarding associated with the new LSP be created on each
LSR hop of the LSP path.
[RFC3209] states that an ingress can transition traffic on to the new
LSP once it receives the RSVP Resv message for the new LSP, and
proceed to tear down the old LSP. In practice, however, the RSVP
Resv message for the new LSP can reach the ingress before one (or
more) LSR(s) have completed programming their forwarding for the new
LSP. In the meantime, if the ingress transitions traffic on to the
new LSP, it will be impacted.
To avoid prematurely transitioning traffic on to the newly
instantiated LSP, it is common for the ingress LSR to delay the
transition of traffic on to the new LSP - either by empirically
determining a suitable wait time, or by continuously probing the
newly created LSP data-path so it can be verified. Several
mechanisms have been defined for the latter including, [RFC5884] and
[I-D.ietf-mpls-self-ping]. Throughout this document we use the term
installation-time to cover both the above waiting and probing.
There are several cases where it is highly desirable that the ingress
LSR installation-time be as minimal as possible. For example, if a
partial failure of resource(s) (e.g. bundle link) along the LSP path
occurs, the traffic that continues to be forwarded along the degraded
resource(s) while ingress LSR undergoes "make-before-break" may
experience congestion and drops. Another case may occur when a
protected link or node fails and the protected traffic gets rerouted
on to the backup path. In this case, while the ingress(es) initiate
"make-before-break" to move traffic away from the backup path to
newly computed path(s) post convergence, the protected rerouted
traffic flowing on the backup path competes for resources with other
protected traffic originally traversing the same path. This
sometimes may lead to congestion drops as backup path becomes
overloaded by with extra traffic traversing its link(s).
Consequently, network operators usually desire to reduce the total
time that the protected rerouted traffic remains on the backup path
(aka. Total Time on Backup (TTOB)) while ingress(es) undergo "make-
before-break" so to reduce the risk of congestion occurring. Other
similar situation may also occur during RSVP-TE soft-preemption of
LSP(s).
This document defines procedures and extensions to RSVP protocol to
allow the ingress to collect TE Data Link Label (DLL) information
that. The ingress can use the collected DLLs to install and
transition traffic on to a newly created LSP as soon as resource
allocation on traversed link(s) is complete. Consequently, this
eliminates the need for any wait time to program the new LSP state
forwarding on traversed LSRs that is usually needed, and allows the
Saad & Swallow Expires April 18, 2016 [Page 3]
Internet-Draft RSVP-TE LSP Instant Install October 2015
"make-before-break" wait time to be reduced to the time to complete
the resource allocation via RSVP on traversed link(s).
1.1. Requirements Language
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 [RFC2119].
2. Overview
When establishing a new RSVP-TE LSP, the ingress computes a path and
signals the LSP using RSVP-TE to allocate resources along the LSP
path. The RSVP-TE extensions defined in this document allow the
ingress to collect the Data Link Labels (DLLs) of TE link(s)
traversed by the LSP.
The DLL of a TE link is a label that is attached to a specific TE
interface and that is programmed in forwarding such that an incoming
packet with a top DLL label will be popped and packet forwarded over
the associateed TE interface.
Once available, the ingress can use the DLL(s) of traversed TE
link(s) to compose a stack of MPLS labels that are prepended on to
packets to be forwarded over the LSP; thereby, steering such packets
over the same path where RSVP-TE resources have been allocated.
3. RSVP-TE Requirements
The RSVP extensions defined in this document enable the ingress to
retrieve information about DLLs of TE link(s) traversed by the LSP
while signaling and installation of normal TE label(s) is under way.
3.1. TE Data Link Label Collection Indication
The ingress node of the LSP SHOULD be capable of indicating whether
the TE DLL information of traversed links are to be collected during
the signaling procedure of setting up an LSP.
3.2. TE Data Link Label Collection
If requested, the DLL information SHOULD be collected during the
setup of an LSP. The LSP ingress can use the collected DLL(s) of
traversed TE link(s) to install the newly created LSP and transition
traffic on to it as soon as resource allocation is complete using
RSVP.
Saad & Swallow Expires April 18, 2016 [Page 4]
Internet-Draft RSVP-TE LSP Instant Install October 2015
The DLL information SHOULD NOT be collected without an explicit
request for it being made by the ingress node.
3.3. TE Data Link Label Update
When the DLL information changes from information collected during
signaling, the relevant
nodes of the LSP SHOULD be capable of updating the DLL information of
the LSP. This means that that the signaling procedure SHOULD be
capable of updating the DLL information.
Changes to TE data link information may indicate a change in the
label value, or protection state associated with the label.
4. Encodings
In order to indicate to nodes that the DLL collection is desired,
this document defines a new flag in the Attribute Flags TLV (see
[RFC5420]), which MAY be carried in an LSP_REQUIRED_ATTRIBUTES or
LSP_ATTRIBUTES Object:
o Bit Number (TBD-1): DLL Collection flag
The DLL Collection flag is meaningful on a Path message. If the DLL
Collection flag is set to 1, it means that the DLL information SHOULD
be reported to the ingress and egress node along the setup of the
LSP.
The rules of the processing of the Attribute Flags TLV are not
changed.
4.1. RRO TE Data Link Label Sub-object
This document defines a new RRO sub-object (ROUTE_RECORD sub-object)
to record the DLL(s) of traversed link(s) of the LSP. Its format is
modeled on the RRO sub-objects defined in RFC 3209 [RFC3209].
The DLL RRO sub-object is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |U| Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Saad & Swallow Expires April 18, 2016 [Page 5]
Internet-Draft RSVP-TE LSP Instant Install October 2015
Type (TBD-2)
TE Data Link Label type.
Length
The Length field contains the total length of the sub-object in
bytes, including the Type and Length fields. The Length MUST be
at least 4, and MUST be a multiple of 4, see [RFC3209].
U (1 bit)
This bit indicates the direction of the label. It is 0 for the
downstream label. It is set to 1 for the upstream label and is
only used on bidirectional LSPs.
Flags
0x01 Global label
Indicates the label will be understood if received on any
interface.
0x02 Local protection available
Indicates that the outgoing link for this DLL is
protected via a local repair mechanism.
0x04 Local protection in use
Indicates that a local repair mechanism is in use to
maintain traffic over this DLL (usually in the face of an
outage of the link it was previously routed over).
C-Type
The C-Type of the included Label Object. Copied from the Label
Object.
Label
This field identifies the label to be used. The format of this
field is identical to the one used by the Label field in
Generalized Label. The interpretation of this field depends on
the type of the link over which the label is used, see [RFC3471].
As described in [RFC3209], the RECORD_ROUTE object is managed as a
stack. The DLL sub-object SHOULD be pushed by the node before the
Saad & Swallow Expires April 18, 2016 [Page 6]
Internet-Draft RSVP-TE LSP Instant Install October 2015
link ipv4/ipv6 address. The DLL sub-object SHOULD be pushed after
the Attribute sub-object, if present, and after the LABEL sub-object,
if requested.
A node MUST NOT push a TE DLL sub-object in the RECORD_ROUTE without
also pushing either a IPv4 sub-object, a IPv6 sub-object, a
Unnumbered Interface ID sub-object.
A node can push multiple DLL sub-object(s) that pertain to the same
link. For example, a policy may necessitate allocating multiple
DLL(s) - e.g. a DLL with no protection, a DLL with NHOP protection,
and another for NNHOP protection. In this case, all the DLL sub-
object(s) pertaining to the link are pushed before pushing the link
identifier.
The rules of the processing of the LSP_REQUIRED_ATTRIBUTES,
LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed.
5. Signaling Procedures
5.1. TE Data Link Label Collection
Per [RFC3209], an ingress node initiates the recording of the route
information of an LSP by adding a RRO to a Path message. If an
ingress node also desires DLL recording, it MUST set the DLL
Collection Flag in the Attribute Flags TLV which MAY be carried
either in an LSP_REQUIRED_ATTRIBUTES Object when the collection is
mandatory, or in an LSP_ATTRIBUTES Object when the collection is
desired, but not mandatory.
When a node receives a Path message which carries an
LSP_REQUIRED_ATTRIBUTES Object and the DLL Collection Flag set, if
local policy determines that the DLL information is not to be
provided to the endpoints, it MUST return a PathErr message with: o
Error Code 2 (policy) and o Error subcode "DLL Recording Rejected"
(value TBD) to reject the Path message.
When a node receives a Path message which carries an LSP_ATTRIBUTES
Object and the DLL Collection Flag set, if local policy determines
that the DLL information is not to be provided to the endpoints, the
Path message SHOULD NOT be rejected due to DLL recording restriction
and the Path message SHOULD be forwarded without any DLL sub-
object(s) in the RRO of the corresponding outgoing Path message.
If local policy permits the recording of the DLL information, the
processing node SHOULD add local DLL information, as defined below,
to the RRO of the corresponding outgoing Path message. The
processing node MAY add multiple DLL sub-objects to the RRO if
Saad & Swallow Expires April 18, 2016 [Page 7]
Internet-Draft RSVP-TE LSP Instant Install October 2015
necessary. It then forwards the Path message to the next node in the
downstream direction.
If the addition of DLL information to the RRO would result in the RRO
exceeding its maximum possible size or becoming too large for the
Path message to contain it, the requested DLL MUST NOT be added. If
the DLL collection request was contained in an
LSP_REQUIRED_ATTRIBUTES Object, the processing node MUST behave as
specified by [RFC3209] and drop the RRO from the Path message
entirely. If the DLL collection request was contained in an
LSP_ATTRIBUTES Object, the processing node MAY omit some or all of
the requested DLL(s) from the RRO; otherwise, it MUST behave as
specified by [RFC3209] and drop the RRO from the Path message
entirely.
Following the steps described above, the intermediate nodes of the
LSP can collect the DLL information in the RRO during the processing
of the Path message hop by hop. When the Path message arrives at the
egress node, the egress node receives DLL information in the RRO.
Per [RFC3209], when issuing a Resv message for a Path message which
contains an RRO, an egress node initiates the RRO process by adding
an RRO to the outgoing Resv message. The processing for RROs
contained in Resv messages then mirrors that of the Path messages.
When a node receives a Resv message for an LSP for which DLL
Collection is specified, then if local policy allows recording DLL
information, the node SHOULD add the DLL information to the RRO of
the corresponding outgoing Resv message, as specified below.
When the Resv message arrives at the ingress node, the ingress node
can extract the DLL information from the RRO in the same way as the
egress node.
Note that the DLL information for the upstream direction cannot be
assumed to be the same as that in the downstream.
o For Path and Resv messages for a unidirectional LSP, a node SHOULD
include the DLL sub-objects in the RRO for the downstream data link
only.
o For Path and Resv messages for a bidirectional LSP, a node SHOULD
include DLL sub-objects in the RRO for both the upstream data link
and the downstream data link from the local node. In this case, the
node MUST include the information in the same order for both Path
messages and Resv messages. That is, the DLL sub- object for the
upstream link is added to the RRO before the DLL sub-object for the
downstream link.
Saad & Swallow Expires April 18, 2016 [Page 8]
Internet-Draft RSVP-TE LSP Instant Install October 2015
Based on the above procedure, the endpoints can get the DLL
information automatically.
5.2. TE Data Link Label Update
When the DLL information of a data link is changed, the RSVP-TE LSPs
traversing that link need to be made aware of the changes. The
procedures defined in Section 4.4.3 of RFC 3209 [RFC3209] MUST be
used to refresh the DLL information if the change is to be
communicated to other nodes according to the local node's policy.
5.3. Compatibility
A node that does not recognize the TE DLL Collection Flag in the
Attribute Flags TLV is expected to proceed as specified in RFC 5420
[RFC5420]. It is expected to pass the TLV on unaltered if it appears
in a LSP_ATTRIBUTES object, or reject the Path message with the
appropriate Error Code and Value if it appears in a
LSP_REQUIRED_ATTRIBUTES object.
A node that does not recognize the DLL RRO sub-object is expected to
behave as specified in RFC 3209 [RFC3209] unrecognized subobjects are
to be ignored and passed on unchanged.
6. Behavior of LSRs for Instant LSP Installation
To use the instant LSP install procedures, the ingress and traversed
LSR(s) will need to support the required RSVP-TE signaling extensions
described earlier for requesting and recording DLL(s) of traversed
link(s) of an LSP as well as to update their behavior as described
below.
6.1. Behavior of Ingress LSR
To be able to carry out instant LSP install procedures, the ingress
of the LSP indicates to traversed nodes to record all DLL(s) of
traversed link(s) of the LSP. This is achieved by the ingress
setting the new flag in the Attribute Flags TLV as described in
section Section 4.
Upon receiving the RSVP Resv message of the newly signaled LSP, the
resource allocation on traversed nodes is declared complete. The
ingress LSR inspects the Resv message RRO contents for presence of
the DLL information for all traversed TE link(s). The DLL(s) of all
traversed link(s) MUST be present in the RRO to be able to proceed
with instant LSP installation procedures.
Saad & Swallow Expires April 18, 2016 [Page 9]
Internet-Draft RSVP-TE LSP Instant Install October 2015
The ingress LSR programs its forwarding to impose the multiple
outgoing label(s) corresponding to the collected DLL(s) in the Resv
RRO - with top label of in the stack being the DLL of the first
traversed TE link, and the bottom of the stack corresponding to the
last TE link of the LSP. The ingress can directly transition traffic
on to the DLL-LSP as soon as the forwarding state is programmed at
the ingress.
In addition to the instant LSP procedures, the ingress LSR invokes
the "make-before-break" procedures to wait for new LSP forwarding
state to be programmed on all LSR(s) before transitioning traffic
from the DLL-LSP on to the new LSP. The ingress LSR transitions
traffic on to the new LSP as soon as it is validated. Note in both
cases, the traffic carried on the DLL-LSP and then on the new LSP
flows along the same set of TE link(s), and the transition from the
DLL-LSP to new LSP is expected to not cause any disruptions to
transported traffic.
6.2. Behavior of All LSRs
To support instant LSP procedures, all LSR(s) are expected to
allocate a DLL label corresponding to each TE data link. An LSR can
allocate multiple DLLs for the same TE link (for example, a DLL that
has backup protection path, and another not). A packet arriving at
an LSR whose top label matches a DLL will get it top label popped and
packet forwarded downstream on the TE link associated with the DLL.
Upon receiving an RSVP Path or Resv message and if the DLL Collection
Flag set in the Attribute Flags TLV, the LSR(s) adds the DLL(s) sub-
object corresponding to the RRO before forwarding the RSVP message.
7. Manageability Considerations
7.1. Policy Configuration
In a border node of inter-domain or inter-layer network, the
following TE DLL processing policy SHOULD be capable of being
configured:
o Whether the Data Link Label(s) of the domain or specific layer
network can be exposed to the nodes outside the domain or layer
network, or whether they SHOULD be summarized, mapped to values that
are comprehensible to nodes outside the domain or layer network, or
removed entirely.
A node using RFC 5553 [RFC5553] and PKS MAY apply the same policy.
Saad & Swallow Expires April 18, 2016 [Page 10]
Internet-Draft RSVP-TE LSP Instant Install October 2015
8. Security Considerations
This document builds on the mechanisms defined in [RFC3473], which
also discusses related security measures. In addition, [RFC5920]
provides an overview of security vulnerabilities and protection
mechanisms for the GMPLS control plane. The procedures defined in
this document permit the transfer of the per link DLL data between
domains during the signaling of LSPs, subject to policy at the domain
boundary. It is recommended that domain boundary policies take the
implications of releasing DLL information into consideration and
behave accordingly during LSP signaling.
9. IANA Considerations
9.1. RSVP Attribute Bit Flags
IANA has created a registry and manages the space of the Attribute
bit flags of the Attribute Flags TLV, as described in section 11.3 of
RFC 5420 [RFC5420], in the "Attribute Flags" section of the "Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters"
registry located in http://www.iana.org/assignments/rsvp-te-
parameters". IANA has made an early allocation in the "Attribute
Flags" section of the mentioned registry that expires on 2015-09-11.
This document introduces a new Attribute Bit Flag:
Bit No Name Attribute Attribute RRO Reference
Flags Path Flags Resv
----------- ---------- ---------- ----------- --- ---------
TBD-1 TE DLL Yes Yes Yes This I-D
collection
flag
9.2. ROUTE_RECORD Object
IANA manages the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters. IANA has made an
early allocation in the Sub-object type 21 ROUTE_RECORD - Type 1
Route Record registry. The early allocation expires on 2015-09-11.
This document introduces a new RRO sub-object:
Value Description Reference
--------------------- ------------------- ---------
TBD-2 DLL sub-object This I-D
Saad & Swallow Expires April 18, 2016 [Page 11]
Internet-Draft RSVP-TE LSP Instant Install October 2015
9.3. Policy Control Failure Error subcodes
IANA manages the assignments in the "Error Codes and Globally-Defined
Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry
located at http://www.iana.org/assignments/rsvp-parameters. IANA has
made an early allocation in the "Sub-Codes - 2 Policy Control
Failure" subsection of the the "Error Codes and Globally-Defined
Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry.
The early allocation expires on 2015-09-11.
This document introduces a new Policy Control Failure Error sub-code:
Value Description Reference
--------------------- ----------------------- ---------
TBD-3 DLL Recording Rejected This I-D
10. References
10.1. Normative References
[I-D.ietf-mpls-self-ping]
Bonica, R., Minei, I., Conn, M., Pacella, D., and L.
Tomotaki, "LSP Self-Ping", draft-ietf-mpls-self-ping-05
(work in progress), October 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, DOI 10.17487/RFC3471, January 2003,
<http://www.rfc-editor.org/info/rfc3471>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI
10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
Saad & Swallow Expires April 18, 2016 [Page 12]
Internet-Draft RSVP-TE LSP Instant Install October 2015
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource
Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, DOI 10.17487/RFC5553, May 2009,
<http://www.rfc-editor.org/info/rfc5553>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <http://www.rfc-editor.org/info/rfc5884>.
10.2. Informative References
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
Authors' Addresses
Tarek Saad
Cisco Systems Inc
Email: tsaad@cisco.com
George Swallow
Cisco Systems Inc
Email: swallow@cisco.com
Saad & Swallow Expires April 18, 2016 [Page 13]
