CCAMP Working Group
Internet Draft Anca Zamfir,
Zafar Ali
Cisco Systems
D. Papadimitriou
Alcatel
Document: draft-zamfir-explicit-resource-
control-bundle-03.txt
Expires: August 2004 February 2004
Component Link Recording and Resource Control for GMPLS Link Bundles
draft-zamfir-explicit-resource-control-bundle-03.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Record Route is a useful administrative tool that has been used
extensively by the service providers. When TE links are bundled,
identification of label resource in RRO is not enough for the
administrative purpose. Network service providers would like to know
the component link within a TE link that is being used by a given
LSP. In other words, when link bundling is used, resource recording
Zamfir, A., Ali, Z., Papadimitroiu, D. [Page 1]
draft-zamfir-explicit-resource-control-bundle-03.txt February 2004
requires mechanisms to specify the component link identifier, along
with the TE link identifier and Label. However, it is not possible to
record component link in the RRO. This draft defines the extensions
to RSVP-TE [RFC3209] to specify component link identifiers for
resource recording purposes.
In this draft, we also define ERO counterpart of the RRO extension.
The ERO extensions are needed to perform explicit label/ resource
control over bundled TE link.
In summary, this draft defines the extensions to RSVP-TE [RFC3209] to
specify component link identifiers for explicit resource control and
recording over GMPLS link bundles.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
[RFC2119].
Routing Area ID Summary
(This section to be removed before publication.)
SUMMARY
This document specifies extensions and mechanisms to RSVP-TE to
provide resource recording and control over GMPLS Link Bundles.
WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA?
This draft defines extensions to and describes the use of RSVP-TE
[RFC3209], [RFC3471], [RFC3473] to specify the component link
identifier for resource recording and explicit resource control over
GMPLS link bundles.
WHY IS IT TARGETED AT THIS WG?
This draft is targeted at this WG, because this it specifies
extensions to [RFC3473] for explicit resource control over GMPLS Link
Bundles [BUNDLE].
RELATED REFERENCES
Please refer to the reference section.
Table of Contents
Zamfir, A., Ali, Z., Papadimitroiu, D. [Page 2]
draft-zamfir-explicit-resource-control-bundle-03.txt February 2004
1. Terminology....................................................3
2. Introduction...................................................3
3. Requirement....................................................4
4. LSP Resource Recording.........................................5
4.1 Component Interface Identifier RRO subobject...............5
4.2 Processing of Component Interface identifier RRO Subobject.6
5. Signaling Component Interface Identifier in ERO................7
5.1 Processing of Component Interface Identifier ERO Subobject.8
6. Forward Compatibility Note....................................10
7. Security Considerations.......................................10
References.......................................................11
Author's Addresses...............................................11
1. Terminology
TE Link - Unless specified otherwise, it refers to a bundled Traffic
Engineering link as defined in [BUNDLE]. Furthermore, the terms TE
Link and bundled TE Link are used interchangeably in this draft.
Component Interface - Refers to a component link in a bundled TE
link.
Component Interface Identifier - Refers to an ID used to uniquely
identify a Component Interface.
2. Introduction
In classical MPLS that deals with unbundled packet switch capable
Traffic Engineering (TE) Links, one of the types of resources that an
LSP originator can control and would like to record are the TE Link
interfaces used by the LSP. The resource control and recording is
done by the use of an explicit route, i.e., EXPLICIT_ROUTE Object
(ERO) and RECORD_ROUTE Object (RRO), respectively.
Link Bundling introduced by [BUNDLE], is used to improve routing
scalability by reducing the amount of TE related information that
needs to be flooded and handled by IGP in a TE network. This is
accomplished by aggregating and abstracting the TE Link resource.
In most scenarios the complete resource identification is left as
a local decision. However, as detailed in Section 3, there are cases
when it is desirable for a non-local (e.g., LSP Head-end) node to
identify completely or partially the LSP resources. Consequently,
Label ERO (Explicit Route Object) and RRO (Record Route Object)
subobjects are defined in [RFC3473] to support Explicit Label Control
and recording.
When link bundling is used to aggregate multiple component links
into a TE link, label is not the only resource that needs to be
Zamfir, A., Ali, Z., Papadimitroiu, D. [Page 3]
draft-zamfir-explicit-resource-control-bundle-03.txt February 2004
identified and recorded. In other words, the TE Link and the Label
specified in the ERO/ RRO objects are not enough to completely
identify the resource. For the bundled TE link case, in order to
fully specify the resources on a link for a given LSP, the component
link needs to be specified along with the label. In the case of bi-
directional LSPs both upstream and downstream information may be
specified. Therefore, explicit resource control and recording over a
bundled TE link also requires ability to specify a component link
within the TE link.
This draft defines extensions to and describes the use of RSVP-TE
[RFC3209], [RFC3471], [RFC3473], and [RFC3477] to specify the
component link identifier for resource recording and explicit
resource control over GMPLS link bundles. Specifically, in this
draft, component interface identifier RRO and ERO subobjects are
defined to complement their Label RRO and ERO counterparts.
Furthermore, procedures for processing component interface identifier
RRO and ERO subobjects and how they can co-exist with the Label RRO
and ERO subobjects are specified.
3. Requirement
Component link recording and resource control for GMPLS Link
Bundles inherits requirements from its Label control and recording
counterpart, which is defined in [RFC3473]. However, there are some
requirements that makes component link recording more useful. In this
section we mainly outline the requirements of component link
recording and control beyond the applications that are motivating
point behind Label control and recording procedure in [RFC3473].
One of the main requirements for component link recording is
diagnostics. Specifically, for administrative reasons, it is required
to know which component link within a bundled TE link has been used
for a given LSP.
In a GMPLS networks itÆs often required to explicitly control LSP
resources over a given path. Furthermore, in component links are
multiplexing capable, component link information is required to pin
the path to the (component link, label) resource pair. Here component
link information, just like its label counterpart, is assumed to be
known to operator via means other than IGP.
Another requirement is induced by SRLG diverse working/protecting
LSP pair computation in applications such as the shared mesh
recovery. This requirement comes from the fact that SRLG of a GMPLS
bundled link is the union of the SRLGs of all the component links
([GMPLS-ROUTING] and [BUNDLE]). This abstraction introduces
additional blocking in establishing SRLG diverse LSPs. Specifically,
the component link recording enables the remote (Head) node to
Zamfir, A., Ali, Z., Papadimitroiu, D. [Page 4]
draft-zamfir-explicit-resource-control-bundle-03.txt February 2004
retrieve (if this information is locally known) the SRLG assigned to
the component link(s), instead of the union of SRLG associated with
the bundled TE link. This allows easier usage of the SRLG XRO
subobject defined in [XRO].
In the same context, the component link control can also be used
to select specific component links with desired SRLG (by the Head/
node performing ERO expansion).
One of the applications of component link recording is to request
component link diversed paths. Specifically, once RRO with component
link recording is received at the ingress node, the node can make use
of the component link information to request diverse path with
respect to component links using the corresponding XRO subobject (see
[XRO])."
Another application of communicating component link level
information is in fault notification. Specifically, a new error code
indicating 'component link failure' in Path Error or Notify message
is defined in [CRANKBACK]. This is to allow an ingress node to NOT
exclude the bundled link with the failed component link.
4. LSP Resource Recording
This refers to the ability to record the resources used by an LSP.
The procedure for unbundled numbered TE links is described in
[RFC3209] and for unbundled unnumbered TE links in [RFC 3477]. For
the purpose of recording LSP resources used over bundled TE Links,
the Component Interface Identifier RRO sub-object is introduced.
4.1 Component Interface Identifier RRO subobject
A new subobject of the Record Route Object (RRO) is used to record
component interface identifier of a (bundled) TE Link. This subobject
has the following format:
Figure 2: Component Interface Identifier RRO subobject
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 (must be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component Interface Identifier |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
L: 1 bit
Zamfir, A., Ali, Z., Papadimitroiu, D. [Page 5]
draft-zamfir-explicit-resource-control-bundle-03.txt February 2004
This bit must be set to 0.
Type
10 (TBD) Component Interface identifier IPv4
11 (TBD) Component Interface identifier IPv6
12 (TBD) Component Interface identifier Unnumbered
Length
The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is
8 bytes for the Component Interface identifier IPv4 and
Component Interface identifier Unnumbered types. For
Component Interface identifier IPv6 type of sub-object, the
length field is 20 bytes.
U: 1 bit
This bit indicates the direction of the component
interface. It is 0 for the downstream interface. It is
set to 1 for the upstream interface and is only used for
bi-directional LSPs.
4.2 Processing of Component Interface identifier RRO Subobject
If a node desires component link recording, the "Component Link
Recording desired" flag (value TBD) should be set in the
LSP_ATTRIBUTES object, object that is defined in [RSVP-TE-ATTRIBUTE].
Another alternate is to use an available flag in the
SESSION_ATTRIBUTE object [RFC3209]. The later makes the component
link recording request similar to the label recording request. These
alternatives need to be discussed with the CCAMP working group and
close accordingly.
Setting of "Component Link Recording desired" flag is independent of
the Label Recording flag in SESSION_ATTRIBUTE object as specified in
[RFC3209]. Nevertheless, the following combinations are valid:
1) If both Label and Component Link flags are clear, then neither
Labels nor Component Links are recorded.
2) If Label Recording flag is set and Component Link flag is
clear, then only Label Recording is performed as defined in
[RFC3209].
3) If Label Recording flag is clear and Component Link flag is
set, then Component Link Recording is performed as defined in this
proposal.
Zamfir, A., Ali, Z., Papadimitroiu, D. [Page 6]
draft-zamfir-explicit-resource-control-bundle-03.txt February 2004
4) If both Label Recording and Component Link flags are set, then
Label Recording is performed as defined in [RFC3209] and also
Component Link recording is performed as defined in this proposal.
In most cases a node initiates recording for a given LSP by adding
the RRO to the Path message. If the node desires Component Link
recording and if the outgoing TE link is bundled, then the initial
RRO contains the Component Link identifier (numbered or unnumbered)
as selected by the sender. As well, the Component Link Recording
desired flag is set in the LSP_ATTRIBUTE object. If the node also
desires label recording, it sets the Label_Recording flag in the
SESSION_ATTRIBUTE object.
When a Path message with the "Component Link Recording desired"
flag set is received by an intermediate node, if a new Path message
is to be sent for a downstream bundled TE link, the node adds a new
Component Link subobject to the RRO and appends the resulting RRO to
the Path message before transmission.
Note that, unlike Labels, Component Link identifiers are always
known on receipt of the Path message.
When the destination node of an RSVP session receives a Path
message with an RRO and the "Component Link Recording desired" flag
set, this indicates that the sender node needs TE route as well as
component link recording. The destination node initiates the RRO
process by adding an RRO to Resv messages. The processing mirrors
that of the Path messages
The Component Interface Record subobject is pushed onto the
RECORD_ROUTE object prior to pushing on the node's IP address. A node
MUST NOT push on a Component Interface Record subobject without also
pushing on the IP address or unnumbered Interface Id subobject that
identifies the TE Link.
When component interfaces are recorded for bi-directional LSPs,
component interface RRO subobjects for both downstream and upstream
interfaces MUST be included.
5. Signaling Component Interface Identifier in ERO
A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is
used to specify component interface identifier of a bundled TE Link.
This subobject has the following format:
Figure 1: Component Interface Identifier ERO subobject
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
Zamfir, A., Ali, Z., Papadimitroiu, D. [Page 7]
draft-zamfir-explicit-resource-control-bundle-03.txt February 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |U| Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4, IPv6 or unnumbered Component Interface Identifier |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: 1 bit
This bit must be set to 0.
Type
10 (TBD) Component Interface identifier IPv4
11 (TBD) Component Interface identifier IPv6
12 (TBD) Component Interface identifier Unnumbered
Length
The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is
8 bytes for the Component Interface identifier types: IPv4
and Component Interface identifier Unnumbered. For
Component Interface identifier IPv6 type of sub-object,
the length field is 20 bytes.
U: 1 bit
This bit indicates the direction of the component
interface. It is 0 for the downstream interface. It is
set to 1 for the upstream interface and is only used for
bi-directional LSPs.
5.1 Processing of Component Interface Identifier ERO Subobject
The Component Interface Identifier ERO subobject follows a subobject
containing the IP address, or the link identifier [RFC3477],
associated with the TE link on which it is to be used. It is used to
identify the component of a bundled TE Link.
The following SHOULD result in "Bad EXPLICIT_ROUTE object" error
being sent upstream by a node processing an ERO that contains the
Component Interface ID sub-object:
o The first component interface identifier subobject is not
preceded by a sub-object containing an IPv4 or IPv6 address, or
an interface identifier [RFC3477], associated with a TE link.
Zamfir, A., Ali, Z., Papadimitroiu, D. [Page 8]
draft-zamfir-explicit-resource-control-bundle-03.txt February 2004
o The Component Interface Identifier ERO subobject follows a
subobject that has the L-bit set.
o On unidirectional LSP setup, there is a Component Interface
Identifier ERO subobject with the U-bit set.
o Two Component Interface Identifier ERO subobjects with the same
U-bit values exist.
If a node implements the component interface identifier subobject,
it must check if it represents a component interface in the bundled
TE Link specified in the preceding subobject that contains the IP
address or interface identifier of the TE Link. If the content of the
component interface identifier subobject does not match a component
interface in the TE link, a "Bad EXPLICIT_ROUTE object" error SHOULD
be reported as "Routing Problem" (error code 24).
If U-bit of the subobject being examined is cleared (0) and the
upstream interface specified in this subobject is acceptable, then
the value of the upstream component interface is copied in the TLV of
the IF_ID HOP object [RFC 3471] and the local decision normally used
to select the upstream component link is bypassed. If this interface
is not acceptable, a "Bad EXPLICIT_ROUTE object" error SHOULD be
reported as "Routing Problem" (error code 24).
If the U-bit of the subobject being examined is set (1), then the
value represents the component interface to be used for upstream
traffic associated with the bidirectional LSP. Again, if this
interface is not acceptable or if the request is not one for a
bidirectional LSP, then a "Bad EXPLICIT_ROUTE object" error SHOULD be
reported as "Routing Problem" (error code 24). Otherwise, the
component interface IP address/ identifier is copied into a TLV sub-
object as part of the IF_ID RSVP_HOP object.
The IF_ID RSVP_HOP object constructed as above MUST be included in
the corresponding outgoing Path message.
Note that, associated with a TE Link sub-object in the ERO, either
the upstream component interface or the downstream component
interface or both may be specified. As specified in [BUNDLE] there is
no relationship between the TE Link type (numbered or unnumbered) and
the Link type of any one of its components.
The component interface identifier ERO subobject is optional.
Similarly, presence of the Label ERO sub-objects is not mandatory
[RFC 3471], [RFC 3473]. Furthermore, component interface identifier
ERO subobject and Label ERO subobject may be included in the ERO
independently of each other. One of the following alternatives
applies:
o When both sub-objects are absent, a node may select any appropriate
component link within the TE link and any label on the selected
component link.
Zamfir, A., Ali, Z., Papadimitroiu, D. [Page 9]
draft-zamfir-explicit-resource-control-bundle-03.txt February 2004
o When the Label subobject is only present for a bundled link, then
the selection of the component link within the bundle is a local
decision and the node may select any appropriate component link,
which can assume the label specified in the Label ERO.
o When only the component interface identifier ERO subobject is
present, a node MUST select the component interface specified in the
ERO and may select any appropriate label value at the specified
component link.
o When both component interface identifier ERO subobject and Label
ERO subobject are present, the node MUST select the specified
component link and the specified label value on that component link.
When present, both subobjects may appear in any relative order to
each other but they MUST appear after the TE Link sub-object that
they refer to.
After processing, the component interface identifier subobjects
are removed from the ERO.
Inferred from above, the interface subobject should never be the
first subobject in a newly received message. If the component
interface subobject is the first subobject in a received ERO, then it
SHOULD be treated as a "Bad strict node" error.
Note: Information to construct the Component Interface ERO subobject
may come from the same mean used to populate the label ERO subobject.
Procedures by which an LSR at the head-end of an LSP obtains the
information needed to construct the Component Interface subobject are
outside the scope of this document.
6. Forward Compatibility Note
The extensions specified in this draft do not affect the
processing of the RRO, ERO at nodes that do not support them. A node
that does not support the Component Interface RRO subobject but that
does support Label subobject SHOULD only insert the Label subobject
in the RRO as per [RFC3471] and [RFC3473]. A node that receives an
ERO that contains a Component Link ID subobject SHOULD send "Bad
EXPLICIT_ROUTE object" if it does not implement this subobject.
As per [RFC3209], Section 4.4.5, a non-compliant node that receives
an RRO that contains Component Interface Identifier sub-objects
should ignore and pass them on.
7. Security Considerations
This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC2205]
remain relevant.
Zamfir, A., Ali, Z., Papadimitroiu, D. [Page 10]
draft-zamfir-explicit-resource-control-bundle-03.txt February 2004
References
[RFC2205] " Resource ReSerVation Protocol (RSVP) - Version 1,
Functional Specification", RFC 2205, Braden, et al, September
1997.
[RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al,
RFC 3209, December 2001.
[BUNDLE] "Link Bundling in MPLS Traffic Engineering", draft-ietf-
mpls-bundle-04.txt, K. Kompella, et al, January 2003.
[GMPLS-ROUTING] ôRouting Extensions in Support of Generalized Multi-
Protocol Label Switchingö, draft-ietf-ccamp-gmpls-routing-09.txt,
K. Kompella, Y. Rekhter, et al, April 2004.
[RFC3471] Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, RFC 3471, L. Berger, et al,
January 2003.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-
TE) Extensions", RFC 3471, L. Berger, et al, January 2003.
[RFC3477] "Signaling Unnumbered Links in Resource ReSerVation
Protocol - Traffic Engineering (RSVP-TE) ", RFC 3477, K. Kompella,
Y. Rekhter, January 2003.
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, S. Bradner, March 1997.
[RSVP-TE-ATTRIBUTE] "Encoding of Attributes for Multiprotocol Label
Switching (MPLS) Label Switched Path (LSP) Establishment Using
RSVP-TE", draft-farrel-mpls-rsvpte-attributes-00.txt., A. Farrel.
et al, April 2004
[XRO] ôExclude Routes - Extension to RSVP-TEö, C.Y. Lee, et al.,
draft-ietf-ccamp-rsvp-te-exclude-route-01.txt.
[CRANKBACK] ôCrankback Signaling Extensions for MPLS Signalingö,
Adrian Farrel, et al., internet-drafts/draft-ietf-ccamp-crankback-
01.txt
Author's Addresses
Anca Zamfir
Cisco Systems Inc.
2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8
Canada.
Phone: (613)-254-3484
Email: ancaz@cisco.com
Zamfir, A., Ali, Z., Papadimitroiu, D. [Page 11]
draft-zamfir-explicit-resource-control-bundle-03.txt February
2004
Zafar Ali
Cisco Systems Inc.
100 South Main St. #200
Ann Arbor, MI 48104
USA.
Phone: (734) 276-2459
Email: zali@cisco.com
Dimitri Papadimitriou (Alcatel)
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
Zamfir, A., Ali, Z. Papadimitroiu, D.
[Page 12]