CCAMP C. Margaria, Ed.
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track R. Casellas
Expires: September 4, 2012 CTTC
O. Gonzalez de Dios
Telefonica Investigacion y
Desarrollo
March 03, 2012
Expressing Label Set in ERO
draft-margaria-ccamp-label-set-ero-00
Abstract
The paths chosen by Generalized MPLS (GMPLS) Traffic Engineering (TE)
Label Switched Paths (LSPs) can be constrained using the Explicit
Route (ERO) object and related sub-objects. Standard ERO sub-objects
can specify the Autonomous System (AS), LSR Node Ids, Numbered or
unnumbered TE links, downstream and upstream labels, and PCE path
keys thus restricting which resources are to be used by a TE-LSP.
The Explicit Label Control (ELC) in the explicit route object (ERO)
allows both terminating an LSP on a particular outgoing port and
label of an egress node, as well as restricting which label to use on
any hop along the path determined by the route. However, currently,
its not allowed to specify more than 2 labels (downstream and
upstream label), and it is not possible to specify, for a given
section or segment of a TE-LSP path, a set of labels to restrict
which label to be allocated from a Set of candidate labels.
This memo provides extensions to the RSVP-TE and PCEP protocols to
support Label Sets in the form of ERO sub-objects, being applicable
to ERO and ERO-like (IRO, RRO, XRO) sub-objects, extending the ELC
concept to a set of candidate labels.
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
Margaria, et al. Expires September 4, 2012 [Page 1]
Internet-Draft Expressing Label Set in ERO March 2012
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 September 4, 2012.
Copyright Notice
Copyright (c) 2012 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 Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Margaria, et al. Expires September 4, 2012 [Page 2]
Internet-Draft Expressing Label Set in ERO March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 5
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Solution overview . . . . . . . . . . . . . . . . . . . . . . 6
3. Multiple consecutive Label ERO subobjects . . . . . . . . . . 7
4. Label Set ERO subobject . . . . . . . . . . . . . . . . . . . 8
4.1. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 8
5. LSP_ATTRIBUTE extensions . . . . . . . . . . . . . . . . . . . 10
5.1. TARGETED_LSP_ATTRIBUTE TLV . . . . . . . . . . . . . . . . 10
5.2. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . 13
6. Evaluation of proposed solution alternatives . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. Label Set ERO subobject . . . . . . . . . . . . . . . . . 15
7.2. LSP_ATTRIBUTE . . . . . . . . . . . . . . . . . . . . . . 15
7.2.1. Attribute Flags . . . . . . . . . . . . . . . . . . . 15
7.2.2. Service ID TLV . . . . . . . . . . . . . . . . . . . . 15
7.2.3. Targeted LSP attribute TLV . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Margaria, et al. Expires September 4, 2012 [Page 3]
Internet-Draft Expressing Label Set in ERO March 2012
1. Introduction
Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched
Paths (LSPs) can be route-constrained by making use of the Explicit
Route (ERO) object and related sub-objects as defined in [RFC3209],
[RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553].
In general, ERO sub-objects identify the resources to be used by a
GMPLS, and can be used to restrict, exclude (IRO/XRO), define (ERO)
or report (RRO) such resources.
The Explicit Label Control (ELC) in the explicit route object (ERO)
allows both terminating an LSP on a particular outgoing port and
label of an egress node, as well as restricting which label to use on
any hop along the path determined by the route. However, currently,
its not allowed to specify more than 2 labels (downstream and
upstream label), and it is not possible to specify, for a given
section or segment of a TE-LSP path, a set of labels to restrict
which label to be allocated from a Set of candidate labels.
On the other hand, [RFC3473] defines the RSVP-TE LABEL_SET object,
which can be used in a Path Message to restrict the choice of the
generalized label, allocated by the downstream node to a set of
labels.
Extending the semantics of the Explicit Label Control to a label set
and restricting / limiting the choice of label within a given Label
Set, while maintaining the applicability of ERO and ERO-like RSVP-TE
and PCEP objects can be beneficial in the following cases:
o To constrain and restrict the choice of a Label at a given port
(including egress port) to be selected from a set of labels but
without strictly enforcing a single value (for example, when
conveying a set of available labels due to hardware limitations
such as tunable wavelengths).
o Due to known label switching constraint on some section of the TE-
LSP path: explicitly specify the label constraint on a specific
link by requesting a Label Set to limit the choice of the label.
o To constraint a distributed wavelength assignment (D-WA) for a TE-
LSP DWDM transparent optical section
o To allow a PCE or any other centralized entity to indicate a set
of labels to be used in signaling, not only in the initial Label
set but in any hop along the path.
o To allow a Path Computation Client (PCC) to indicate, as an input
constraint when requesting a combined R&WA computation to a PCE,
Margaria, et al. Expires September 4, 2012 [Page 4]
Internet-Draft Expressing Label Set in ERO March 2012
which set of wavelengths are acceptable at a given TE link,
transparent segment or end-to-end path, depending on the label
(wavelength) continuity restrictions of the underlying data plane.
o To exclude (i.e., in a XRO object) a set of Labels from being
considered in a label allocation, reusing the efficient encoding
that has been proposed for Label sets and Label set ERO sub-
objects.
o To control resource sharing for pre-planned protecting LSP, where
one can indicate which labels should be shared in addition to the
PPRO disjointness constraints.
1.1. Contributing Authors
1.2. 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 RFC 2119.
Margaria, et al. Expires September 4, 2012 [Page 5]
Internet-Draft Expressing Label Set in ERO March 2012
2. Solution overview
In order to support specifying several labels as a potential set of
labels to be used when allocating a label, several solutions are
applicable and described in this document:
Allowing several consecutive Label ERO subobjects in an ERO
object.
Defining a Label Set ERO subobject to be used in an ERO (and
similar) object.
Extending the LSP_ATTRIBUTES object with a new TLV targeting
attributes at a given node.
A short overview of each solution is provided in the next sections
and an evaluation of each one on is provided afterwards.
Margaria, et al. Expires September 4, 2012 [Page 6]
Internet-Draft Expressing Label Set in ERO March 2012
3. Multiple consecutive Label ERO subobjects
This approach would require relaxing the rules that define how Label
sub-objects are used within an ERO/XRO/RRO object, and notably in
what concerns Explicit Label Control. In particular, the procedure
described in [RFC3473] section 5.1.1 is modified as follows:
The following SHOULD NOT result in a "Bad EXPLICIT_ROUTE object"
errors:
For there to be two label subobjects with the same U-bit values
It is allowed to have several consecutive Label subobects with the
same U-bit values, which become equally valid alternatives for the
downstream label.
To support the label subobject, a node must check to see if one or
more sub-objects following its associated address/interface sub-
objects are label subobjects. If this is the case, the sub-objects
are examined: a RSVP-TE LABEL_SET object (Type 36) is constructed
with the values of the labels that have the U-bit cleared. This
LABEL_SET object MUST be included in the outgoing Path message and
MAY be splitted into several LABEL_SET objects (LABEL_SET for the
downstream direction). Note that this LABEL_SET does not replace the
existing LABEL_SET and MAY be merged with it.
The new Label_Set objects included in the Path message do not replace
existing Label_Set object.
If the U-bit of the subobject being examined is set (1), then the set
of value of the Label subobject with U bit set should be used to
restrict the choice of the upstream label associated with the
bidirectional LSP. If this label is not acceptable, a "Bad
EXPLICIT_ROUTE object" error SHOULD be generated. If the label is
acceptable, the assigned label is copied into a new Upstream_Label
object. This Upstream_Label object MUST be included on the
corresponding outgoing Path message.
Margaria, et al. Expires September 4, 2012 [Page 7]
Internet-Draft Expressing Label Set in ERO March 2012
4. Label Set ERO subobject
In this solution a new Label Set subobject is defined.
The Label Set ERO subobject 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |U| Reserved | C-Type(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Set |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC3471] for a description of L,U and Label Set parameters.
Type x Label Set
Length The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is always
divisible by 4.
C-Type The C-Type of the included Label Object. Copied from the
Label Object.
4.1. Procedures
The Label Set subobject follows a similar procedure to the
aforementioned one that is used when several Label sub-objects are
allowed. The Label Set subobject must follow a subobject identifying
the link where the Label Set is applicable (a subobject containing a
IP address or an interface identifier) or a previous Label Set
subobject. Several Label Set subobject may be present. The
following SHOULD result in "bad EXPLICIT_ROUTE object" errors:
If the first Label Set subobject is not preceded by a subobject
containing an IP address or an interface identifier associated
with an output link
On unidirectional LSP setup, for there to be a label set subobject
with the U-bit set
It is not allowed to mix Label Set and Label subobject.
The following text is adapted from the Label subobject procedure
described in [RFC3473]
Margaria, et al. Expires September 4, 2012 [Page 8]
Internet-Draft Expressing Label Set in ERO March 2012
To support the label set subobject, a node must check to see if the
subobject following its associate address/interface is a label set
subobject. If it is, the following subobjects are examined. If the
U-bit of the subobject being examined is clear (0), then value of the
label set is copied into a a RSVP-TE LABEL_SET object (Type 36). One
LABEL_SET object MUST be included in the outgoing Path message. The
LABEL-SET object MAY be splitted into several LABEL_SET objects or
MAY be merged with the existing LABEL-SET objects of this LSP.
If the U-bit of the subobject being examined is set (1), then value
of the label set is used to choose the label to be used for upstream
traffic associated with the bidirectional LSP. If this label is not
acceptable, a "Bad EXPLICIT_ROUTE object" error SHOULD be generated.
If the label set is acceptable and a label assigned, the label is
copied into a new Upstream_Label object. This Upstream_Label object
MUST be included on the corresponding outgoing Path message.
After processing, the label set subobjects are removed from the ERO.
Note an implication of the above procedures is that the label set
subobject should never be the first subobject in a newly received
message. If the label subobject is the the first subobject an a
received ERO, then it SHOULD be treated as a "Bad strict node" error.
Procedures by which an LSR at the head-end of an LSP obtains the
information needed to construct the Label Set subobject are outside
the scope of this document.
Margaria, et al. Expires September 4, 2012 [Page 9]
Internet-Draft Expressing Label Set in ERO March 2012
5. LSP_ATTRIBUTE extensions
In order to indicate, at a given hop or interface within the ERO, a
set of candidate labels to be used when selecting the generalized
label, it is also possible to use LSP_ATTRIBUTE extensions [RFC5240]
. To this end, the procedure to generate the outgoing RSVP-TE Path
message LABEL_SET object from the information contained in the
LSP_ATTRIBUTE is similar conceptually to the previous ones. The
following new TLVs are required for this solution :
o a TLV indicating attributes for a node/interface (one per node/
interface)
o This TLV will contain sub-TLV, here:
* Attribute Flag TLV
* A Label Set TLV
* Any Attribute TLV which are applicable to a specific Node/
interface
A new flag should be defined for the Targeted LSP attribute,
requiring this will then depend in which object this is added. The
Label Set TLV also required a new flag, but it SHOULD NOT appear
directly in the LSP_ATTRIBUTE, this solution add TLVs that can be
scoped only to specific interface or node. The RRO subobject
attribute processing is not modified, a Node MAY report all the bits
from the Attribute flag TLV in LSP_ATTRIBUTES or/and
LSP_REQUIERED_ATTRIBUTES or/and the Attribute flag TLV in the
TARGETED_LSP_ATTRIBUTE TLV.
5.1. TARGETED_LSP_ATTRIBUTE TLV
A new TLV is introduced, the TARGETED_LSP_ATTRIBUTE TLV, which is
valid on Path message only in LSP_ATTRIBUTE and
LSP_REQUIRED_ATTRIBUTES Object.
Margaria, et al. Expires September 4, 2012 [Page 10]
Internet-Draft Expressing Label Set in ERO March 2012
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 | Identifier Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Identifier (Variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type x
Length The Length contains the total length of the subobject in
bytes, including the Type and Length fields. This length must be
a multiple of four and must be at least eight.
Identifier Type The type of identifier used, currently the following
types are defined:
0 IPv4 address
1 IPv6 address
2 Unnumbered address
Identifier Depending on the Identifier type this field contains:
IPv4 address A 32 bit IPv4 address
IPv6 address A 128 bit IPv6 Address
Unnumbered address A 64 bit field containing a 32 bit Node Id and
32 bit unnumbered address
TLVs A list of TLVs
An IPv4 Identifier type
Margaria, et al. Expires September 4, 2012 [Page 11]
Internet-Draft Expressing Label Set in ERO March 2012
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 | Identifier Type=0 (IPv4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An IPv6 Identifier type
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 | Identifier Type=1 (IPv6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An Unnumbered interface identifier
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 | Identifier Type=2 (Unnumbered)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unnumbered interface id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Margaria, et al. Expires September 4, 2012 [Page 12]
Internet-Draft Expressing Label Set in ERO March 2012
5.2. PCEP Extensions
This solution does not fit to existing PCEP object, One possible
solution would be to map the RSVP LSP_ATTRIBUTE logic to PCEP LSPA
object and define a set of LSPA TLVs carrying relevant LSP_ATTRIBUTE
TLVs. This is for further study.
Margaria, et al. Expires September 4, 2012 [Page 13]
Internet-Draft Expressing Label Set in ERO March 2012
6. Evaluation of proposed solution alternatives
The First two solutions would easily allow a centralized entity such
as a PCE or a NMS to add this per-hop constraints information but
would imply a greater impact to existing deployments. Let us note
that, in general, a PCE currently uses the existing ERO sub-objects
(with different semantics) in the following PCEP sub-objects.
o ERO - to indicate the result of a Path Computation given one or
more requests.
o IRO - to specify which elements, resources, etc. must be used in a
path computation.
o XRO - to specify which elements, resources, etc. must be excluded
in a path computation.
o RRO - to report of existing Paths
Making use of the LSP_ATTRIBUTES would reduce the impact on existing
deployment yet allow to mandate the support of the attribute if
desired, but will introduce several source for Label information.
Margaria, et al. Expires September 4, 2012 [Page 14]
Internet-Draft Expressing Label Set in ERO March 2012
7. IANA Considerations
7.1. Label Set ERO subobject
IANA is requested to make the following subobject allocations from
the "EXPLICIT_ROUTE Subobject Type" registry.
Sub-object type TBA
Name Label Set
Reference This document
7.2. LSP_ATTRIBUTE
IANA is request to add the following information for each TLV in the
RSVP TLV type identifier registry.
o Whether allowed on TARGETED_LSP_ATTRIBUTE TLV
The existing registry is modified for existing TLVs.
7.2.1. Attribute Flags
The new TLV type definition is as follow
o TLV Type = 1
o TLV Name = Attribute Flags TLV
o Allowed on LSP_ATTRIBUTES object
o Allowed on LSP_REQUIRED_ATTRIBUTES object
o Allowed on TARGETED_LSP_ATTRIBUTE TLV
7.2.2. Service ID TLV
The new TLV type definition is as follow
o TLV Type = 1
o TLV Name = Attribute Flags TLV
o Allowed on LSP_ATTRIBUTES object
Margaria, et al. Expires September 4, 2012 [Page 15]
Internet-Draft Expressing Label Set in ERO March 2012
o Not allowed on LSP_REQUIRED_ATTRIBUTES object
o Not allowed on TARGETED_LSP_ATTRIBUTE TLV
7.2.3. Targeted LSP attribute TLV
IANA is requested to make the following allocations from the RSVP
Attribute TLV Space registry.
o TLV Type = n
o TLV Name = Targeted LSP attribute TLV
o Allowed on LSP_ATTRIBUTES object
o Allowed on LSP_REQUIRED_ATTRIBUTES object
o Not allowed on TARGETED_LSP_ATTRIBUTE TLV
IANA is request to make the following allocation from the RSVP
Attribute Flags registry
Bit Name Attribute Flags Attribute Flags RRO Reference
No Path Resv
9 Targeted LSP Yes No Yes This
Attribute document
10 Label Set Yes No No This
document
Margaria, et al. Expires September 4, 2012 [Page 16]
Internet-Draft Expressing Label Set in ERO March 2012
8. Security Considerations
None.
Margaria, et al. Expires September 4, 2012 [Page 17]
Internet-Draft Expressing Label Set in ERO March 2012
9. Contributing Authors
Margaria, et al. Expires September 4, 2012 [Page 18]
Internet-Draft Expressing Label Set in ERO March 2012
10. Acknowledgments
The research leading to these results has received funding from the
European Community's Seventh Framework Program FP7/2007-2013 under
grant agreement no 247674.
Margaria, et al. Expires September 4, 2012 [Page 19]
Internet-Draft Expressing Label Set in ERO March 2012
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC5240] Joshi, B. and R. Bijlani, "Protocol Independent Multicast
(PIM) Bootstrap Router MIB", RFC 5240, June 2008.
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
Topology Confidentiality in Inter-Domain Path Computation
Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource
Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, May 2009.
11.2. Informative References
[I-D.ietf-pce-gmpls-aps-req]
Caviglia, D., Zhang, F., Ogaki, K., and T. Otani,
"Document:", draft-ietf-pce-gmpls-aps-req-05 (work in
progress), January 2012.
Margaria, et al. Expires September 4, 2012 [Page 20]
Internet-Draft Expressing Label Set in ERO March 2012
Authors' Addresses
Cyril Margaria (editor)
Nokia Siemens Networks
St Martin Strasse 76
Munich, 81541
Germany
Phone: +49 89 5159 16934
Email: cyril.margaria@nsn.com
Ramon Casellas
CTTC
Av. Carl Friedrich Gauss n.7
Castelldefels, Barcelona
Spain
Phone: +34 93 645 29 00
Email: ramon.casellas@cttc.es
Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo
C/ Emilio Vargas 6
Madrid, 28043
Spain
Phone: +34 91 3374013
Email: ogondio@tid.es
Margaria, et al. Expires September 4, 2012 [Page 21]