draft-ietf-mpls-explicit-resource-control-bundle-02.txt   draft-ietf-mpls-explicit-resource-control-bundle-03.txt 
MPLS Working Group Network Working Group Anca Zamfir
Internet Draft Anca Zamfir Internet Draft Zafar Ali
Zafar Ali Expires: September 29, 2008 Cisco Systems
Cisco Systems Dimitri Papadimitriou
D. Papadimitriou Alcatel-Lucent
Alcatel March 30, 2008
Document: draft-ietf-mpls-explicit-
resource-control-bundle-02.txt
Expires: April 2006 October 2006
Component Link Recording and Resource Control for GMPLS Link Bundles Component Link Recording and Resource Control for TE Link Bundles
draft-ietf-mpls-explicit-resource-control-bundle-02.txt draft-ietf-mpls-explicit-resource-control-bundle-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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/1id-abstracts.html
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 September 29, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
Record Route is a useful administrative tool that has been used Record Route is a useful administrative tool that has been used
extensively by the service providers. However, when TE links are extensively by the service providers. However, when TE links are
bundled, identification of label resource in RRO is not enough for bundled, identification of label resource in Record Route Object
the administrative purpose. Network service providers would like to (RRO) is not enough for the administrative purpose. Network service
know the component link within a TE link that is being used by a
Zamfir, A., Ali, Z., Papadimitriou, D.
draft-ietf-mpls-mpls-explicit-resource-control-bundle-02.txt Feb. 2006 Component Link Record. & Resource Control for TE Link Bundles Mar.2008
given LSP. In other words, when link bundling is used, resource providers would like to know the component link within a TE link that
recording requires mechanisms to specify the component link is being used by a given LSP. In other words, when link bundling is
identifier, along with the TE link identifier and Label. As , it is used, resource recording requires mechanisms to specify the component
not possible to record component link in the RRO, this draft defines link identifier, along with the TE link identifier and Label. As it
the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify is not possible to record component link in the RRO, this draft
defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify
component link identifiers for resource recording purposes. component link identifiers for resource recording purposes.
This draft also defines the ERO counterpart of the RRO extension. The This draft also defines the Explicit Route Object (ERO) counterpart
ERO extensions are needed to perform explicit label/ resource control of the RRO extension. The ERO extensions are needed to perform
over bundled TE link. Hence, this draft defines the extensions to explicit label/ resource control over bundled TE link. Hence, this
RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to
for explicit resource control and recording over GMPLS link bundles. specify component link identifiers for explicit resource control and
recording over TE link bundles.
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. Terminology....................................................2 1. Terminology....................................................2
2. Resource Control and Recording.................................3 2. Resource Control and Recording.................................3
3. LSP Resource Recording.........................................4 3. LSP Resource Recording.........................................4
3.1 Component Interface Identifier RRO subobject...............4 3.1 Component Interface Identifier RRO subobject...............4
3.2 Processing of Component Interface identifier RRO Subobject.5 3.2 Processing of Component Interface identifier RRO Subobject.5
4. Signaling Component Interface Identifier in ERO................6 4. Signaling Component Interface Identifier in ERO................6
4.1 Processing of Component Interface Identifier ERO Subobject.7 4.1 Processing of Component Interface Identifier ERO Subobject.7
5. Forward Compatibility Note.....................................9 5. Forward Compatibility Note.....................................9
6. Security Considerations........................................9 6. Security Considerations........................................9
7. IANA Considerations...........................................10 7. IANA Considerations...........................................10
8. Intellectual Property Considerations..........................10 8. References....................................................10
9. References....................................................10 8.1 Normative Reference.......................................10
9.1 Normative Reference.......................................10 8.2 Informative Reference.....................................11
9.2 Informative Reference.....................................11 9. Author's Addresses............................................11
10. Author's Addresses...........................................11 10. Intellectual Property Considerations.........................12
11. Full Copyright Statement.....................................11 11. Full Copyright Statement.....................................12
Component Link Record. & Resource Control for TE Link Bundles Mar.2008
1. Terminology 1. Terminology
TE Link: Unless specified otherwise, it refers to a bundled Traffic TE Link: Unless specified otherwise, it refers to a bundled Traffic
Engineering link as defined in [BUNDLE]. Furthermore, the terms TE Engineering link as defined in [RFC4201]. Furthermore, the terms TE
Link and bundled TE Link are used interchangeably in this draft. Link and bundled TE Link are used interchangeably in this draft.
Zamfir, A., Ali, Z., Papadimitriou, D
draft-ietf-mpls-explicit-resource-control-bundle-02.txt Feb. 2006
Component (interface) link: refers (locally) to a component link as Component (interface) link: refers (locally) to a component link as
part of a bundled TE link. A component link is numbered/ unnumbered part of a bundled TE link. A component link is numbered/ unnumbered
in its own right. For unnumbered component links, the component link in its own right. For unnumbered component links, the component link
ID is assumed to be unique on an advertising node. For numbered ID is assumed to be unique on an advertising node. For numbered
component links, the component link ID is assumed to be unique within component links, the component link ID is assumed to be unique within
a domain. a domain.
Component Interface Identifier: Refers to an ID used to uniquely Component Interface Identifier: Refers to an ID used to uniquely
identify a Component Interface. On a bundled link a combination of identify a Component Interface. On a bundled link a combination of
<component link identifier, label> is sufficient to unambiguously <component link identifier, label> is sufficient to unambiguously
identify the appropriate resources used by an LSP [BUNDLE]. identify the appropriate resources used by an LSP [RFC4201].
2. Resource Control and Recording 2. Resource Control and Recording
In GMPLS networks that deals with unbundled (being either PSC, L2SC, In GMPLS networks that deals with unbundled (being either PSC, L2SC,
TDM or LSC) TE Links, one of the types of resources that an LSP TDM or LSC) TE Links, one of the types of resources that an LSP
originator can control and would like to record are the TE Link originator can control and would like to record are the TE Link
interfaces used by the LSP. The resource control and recording is interfaces used by the LSP. The resource control and recording is
done by the use of an explicit route, i.e., Explicit Route (ERO) done by the use of an explicit route, i.e., Explicit Route (ERO)
Object and record Route, i.e., Record Route Object (RRO) object, Object and record Route, i.e., Record Route Object (RRO) object,
respectively. respectively.
Link Bundling introduced by [BUNDLE], is used to improve routing Link Bundling, introduced in [RFC4201], is used to improve routing
scalability by reducing the amount of TE related information that scalability by reducing the amount of TE related information that
needs to be flooded and handled by IGP in a TE network. This is needs to be flooded and handled by IGP in a TE network. This is
accomplished by aggregating and abstracting the TE Link resource. In accomplished by aggregating and abstracting the TE Link resource. In
some cases the complete resource identification is left as a local some cases the complete resource identification is left as a local
decision. However, as described above there are cases when it is decision. However, as described above there are cases when it is
desirable for a non-local (e.g., LSP head-end) node to identify desirable for a non-local (e.g., LSP head-end) node to identify
completely or partially the LSP resources. In either case, for completely or partially the LSP resources. In either case, and for
administrative reasons, it is required to know which component link administrative reasons, it is required to know which component link
within a bundled TE link has been used for a given LSP. within a bundled TE link has been used for a given LSP.
When link bundling is used to aggregate multiple component links into When link bundling is used to aggregate multiple component links into
a TE link, label is not the only resource that needs to be identified a TE link, label is not the only resource that needs to be identified
and recorded. In other words, the TE Link and the Label specified in and recorded. In other words, the TE Link and the Label specified in
the ERO/ RRO objects are not enough to completely identify the the ERO/ RRO objects are not enough to completely identify the
resource. For the bundled TE link case, in order to fully specify 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 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 specified along with the label. In the case of bi-directional LSPs
both upstream and downstream information may be specified. Therefore, both upstream and downstream information may be specified. Therefore,
explicit resource control and recording over a bundled TE link also explicit resource control and recording over a bundled TE link also
requires ability to specify a component link within the TE link. requires ability to specify a component link within the TE link.
Component Link Record. & Resource Control for TE Link Bundles Mar.2008
This draft defines extensions to and describes the use of RSVP-TE This draft defines extensions to and describes the use of RSVP-TE
[RFC3209], [RFC3471], [RFC3473] to specify the component link [RFC3209], [RFC3471], [RFC3473] to specify the component link
identifier for resource recording and explicit resource control over identifier for resource recording and explicit resource control over
GMPLS link bundles. Specifically, in this document, component TE link bundles. Specifically, in this document, component interface
identifier RRO and ERO subobjects are defined to complement their
Zamfir, A., Ali, Z., Papadimitriou, D Label RRO and ERO counterparts. Furthermore, procedures for
draft-ietf-mpls-explicit-resource-control-bundle-02.txt Feb. 2006
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 processing component interface identifier RRO and ERO subobjects and
how they can co-exist with the Label RRO and ERO subobjects are how they can co-exist with the Label RRO and ERO subobjects are
specified. specified.
3. LSP Resource Recording 3. LSP Resource Recording
This refers to the ability to record the resources used by an LSP. LSP Resource Recording refers to the ability to record the resources
used by an LSP.
The procedure for unbundled numbered TE links is described in The procedure for unbundled numbered TE links is described in
[RFC3209] and for unbundled unnumbered TE links in [RFC 3477]. For [RFC3209] and for unbundled unnumbered TE links in [RFC3477]. For the
the purpose of recording LSP resources used over bundled TE Links, purpose of recording LSP resources used over bundled TE Links, the
the Component Interface Identifier RRO sub-object is introduced. Component Interface Identifier RRO sub-object is introduced.
3.1 Component Interface Identifier RRO subobject 3.1 Component Interface Identifier RRO subobject
A new subobject of the Record Route Object (RRO) is used to record A new subobject of the Record Route Object (RRO) is used to record
component interface identifier of a (bundled) TE Link. This subobject component interface identifier of a (bundled) TE Link. This subobject
has the following format: has the following format:
Figure 2: Component Interface Identifier RRO subobject
0 1 2 3 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 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) | |L| Type | Length |U| Reserved (must be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IPv4, IPv6 or unnumbered Component Interface Identifier // // IPv4, IPv6 or unnumbered Component Interface Identifier //
| . . . | | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
L: 1 bit L: 1 bit
This bit must be set to 0. This bit must be set to 0.
Type Type
10 (TBD) Component Interface identifier IPv4 Type 10 (TBD): Component Interface identifier IPv4
11 (TBD) Component Interface identifier IPv6 Type 11 (TBD): Component Interface identifier IPv6
12 (TBD) Component Interface identifier Unnumbered Type 12 (TBD): Component Interface identifier Unnumbered
Length Length
Zamfir, A., Ali, Z., Papadimitriou, D Component Link Record. & Resource Control for TE Link Bundles Mar.2008
draft-ietf-mpls-explicit-resource-control-bundle-02.txt Feb. 2006
The Length contains the total length of the subobject in The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is bytes, including the Type and Length fields. The Length is
8 bytes for the Component Interface identifier IPv4 and 8 bytes for the Component Interface identifier IPv4 and
Component Interface identifier Unnumbered types. For Component Interface identifier Unnumbered types. For
Component Interface identifier IPv6 type of sub-object, the Component Interface identifier IPv6 type of sub-object, the
length field is 20 bytes. length field is 20 bytes.
U: 1 bit U: 1 bit
This bit indicates the direction of the component This bit indicates the direction of the component
interface. It is 0 for the downstream interface. It is interface. It is 0 for the downstream interface. It is
set to 1 for the upstream interface and is only used for set to 1 for the upstream interface and is only used for
bi-directional LSPs. bi-directional LSPs.
3.2 Processing of Component Interface identifier RRO Subobject 3.2 Processing of Component Interface identifier RRO Subobject
If a node desires component link recording, the "Component Link If a node desires component link recording, the "Component Link
Recording desired" flag (value TBD) should be set in the Recording desired" flag (value TBD) should be set in the
LSP_ATTRIBUTES object, object that is defined in [RSVP-TE-ATTRIBUTE]. LSP_ATTRIBUTES object, object that is defined in [RFC4420].
Setting of "Component Link Recording desired" flag is independent of Setting of "Component Link Recording desired" flag is independent of
the Label Recording flag in SESSION_ATTRIBUTE object as specified in the Label Recording flag in SESSION_ATTRIBUTE object as specified in
[RFC3209]. Nevertheless, the following combinations are valid: [RFC3209]. Nevertheless, the following combinations are valid:
1) If both Label and Comp Link flags are clear, then neither
1) If both Label and Component Link flags are clear, then neither
Labels nor Component Links are recorded. Labels nor Component Links are recorded.
2) If Label Recording flag is set and Component Link flag is 2) If Label Recording flag is set and Component Link flag is
clear, then only Label Recording is performed as defined in clear, then only Label Recording is performed as defined in
[RFC3209]. [RFC3209].
3) If Label Recording flag is clear and Component Link flag is 3) If Label Recording flag is clear and Component Link flag is
set, then Component Link Recording is performed as defined in this set, then Component Link Recording is performed as defined in this
proposal. proposal.
4) If both Label Recording and Component Link flags are set, then 4) If both Label Recording and Component Link flags are set, then
Label Recording is performed as defined in [RFC3209] and also Label Recording is performed as defined in [RFC3209] and also
Component Link recording is performed as defined in this proposal. Component Link recording is performed as defined in this proposal.
In most cases, a node initiates recording for a given LSP by adding 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 the RRO to the Path message. If the node desires Component Link
recording and if the outgoing TE link is bundled, then the initial recording and if the outgoing TE link is bundled, then the initial
RRO contains the Component Link identifier (numbered or unnumbered) RRO contains the Component Link identifier (numbered or unnumbered)
as selected by the sender. As well, the Component Link Recording as selected by the sender. As well, the Component Link Recording
desired flag is set in the LSP_ATTRIBUTE object. If the node also desired flag is set in the LSP_ATTRIBUTE object. If the node also
skipping to change at page 5, line 49 skipping to change at page 6, line 5
In most cases, a node initiates recording for a given LSP by adding 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 the RRO to the Path message. If the node desires Component Link
recording and if the outgoing TE link is bundled, then the initial recording and if the outgoing TE link is bundled, then the initial
RRO contains the Component Link identifier (numbered or unnumbered) RRO contains the Component Link identifier (numbered or unnumbered)
as selected by the sender. As well, the Component Link Recording as selected by the sender. As well, the Component Link Recording
desired flag is set in the LSP_ATTRIBUTE object. If the node also desired flag is set in the LSP_ATTRIBUTE object. If the node also
desires label recording, it sets the Label_Recording flag in the desires label recording, it sets the Label_Recording flag in the
SESSION_ATTRIBUTE object. SESSION_ATTRIBUTE object.
Component Link Record. & Resource Control for TE Link Bundles Mar.2008
When a Path message with the "Component Link Recording desired" flag 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 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 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 Component Link subobject to the RECORD_ROUTE object (RRO) and appends
the Path message before transmission. the resulting RRO to the Path message before transmission.
Zamfir, A., Ali, Z., Papadimitriou, D
draft-ietf-mpls-explicit-resource-control-bundle-02.txt Feb. 2006
Note also that, unlike Labels, Component Link identifiers are always Note also that, unlike Labels, Component Link identifiers are always
known on receipt of the Path message. known on receipt of the Path message.
When the destination node of an RSVP session receives a 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 with an RRO and the "Component Link Recording desired" flag set, this
indicates that the sender node needs TE route as well as component indicates that the sender node needs TE route as well as component
link recording. The destination node initiates the RRO process by link recording. The destination node initiates the RRO process by
adding an RRO to Resv messages. The processing mirrors that of the adding an RRO to Resv messages. The processing mirrors that of the
Path messages Path messages
The Component Interface Record subobject is pushed onto the The Component Interface Record subobject is pushed onto the
RECORD_ROUTE object prior to pushing on the node's IP address. A node RECORD_ROUTE object (RRO) prior to pushing on the node's IP address.
MUST NOT push on a Component Interface Record subobject without also A node MUST NOT push on a Component Interface Record subobject
pushing on the IP address or unnumbered Interface Id subobject that without also pushing on the IP address or unnumbered Interface Id
identifies the TE Link. subobject that identifies the TE Link.
When component interfaces are recorded for bi-directional LSPs, When component interfaces are recorded for bi-directional LSPs,
component interface RRO subobjects for both downstream and upstream component interface RRO subobjects for both downstream and upstream
interfaces MUST be included. interfaces MUST be included.
4. Signaling Component Interface Identifier in ERO 4. Signaling Component Interface Identifier in ERO
A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used
to specify component interface identifier of a bundled TE Link. to specify component interface identifier of a bundled TE Link.
This subobject has the following format: This Component Interface Identifier subobject has the following
format:
Figure 1: Component Interface Identifier ERO subobject
0 1 2 3 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 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) | |L| Type | Length |U| Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IPv4, IPv6 or unnumbered Component Interface Identifier // // IPv4, IPv6 or unnumbered Component Interface Identifier //
| . . . | | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: 1 bit L: 1 bit
This bit must be set to 0. This bit must be set to 0.
Type Type
10 (TBD) Component Interface identifier IPv4 Component Link Record. & Resource Control for TE Link Bundles Mar.2008
11 (TBD) Component Interface identifier IPv6
Zamfir, A., Ali, Z., Papadimitriou, D
draft-ietf-mpls-explicit-resource-control-bundle-02.txt Feb. 2006
12 (TBD) Component Interface identifier Unnumbered Type 10 (TBD): Component Interface identifier IPv4
Type 11 (TBD): Component Interface identifier IPv6
Type 12 (TBD): Component Interface identifier Unnumbered
Length Length
The Length contains the total length of the subobject in The Length contains the total length of the subobject in
bytes, including the Type and Length fields. The Length is bytes, including the Type and Length fields. The Length is
8 bytes for the Component Interface identifier types: IPv4 8 bytes for the Component Interface identifier types: IPv4
and Component Interface identifier Unnumbered. For and Component Interface identifier Unnumbered. For Component
Component Interface identifier IPv6 type of sub-object, Interface identifier IPv6 type of sub-object, the length field
the length field is 20 bytes. is 20 bytes.
U: 1 bit U: 1 bit
This bit indicates the direction of the component
interface. It is 0 for the downstream interface. It is This bit indicates the direction of the component interface.
set to 1 for the upstream interface and is only used for It is 0 for the downstream interface. It is set to 1 for the
bi-directional LSPs. upstream interface and is only used for bi-directional LSPs.
4.1 Processing of Component Interface Identifier ERO Subobject 4.1 Processing of Component Interface Identifier ERO Subobject
The Component Interface Identifier ERO subobject follows a subobject The Component Interface Identifier ERO subobject follows a subobject
containing the IP address, or the link identifier [RFC3477], 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 associated with the TE link on which it is to be used. It is used to
identify the component of a bundled TE Link. identify the component of a bundled TE Link.
The following SHOULD result in "Bad EXPLICIT_ROUTE object" error The following SHOULD result in "Bad EXPLICIT_ROUTE object" error
being sent upstream by a node processing an ERO that contains the being sent upstream by a node processing an ERO that contains the
Component Interface ID sub-object: Component Interface ID sub-object:
o The first component interface identifier subobject is not o) The first component interface identifier subobject is not
preceded by a sub-object containing an IPv4 or IPv6 address, or preceded by a sub-object containing an IPv4 or IPv6 address, or
an interface identifier [RFC3477], associated with a TE link. an interface identifier [RFC3477], associated with a TE link.
o The Component Interface Identifier ERO subobject follows a
o) The Component Interface Identifier ERO subobject follows a
subobject that has the L-bit set. subobject that has the L-bit set.
o On unidirectional LSP setup, there is a Component Interface
o) On unidirectional LSP setup, there is a Component Interface
Identifier ERO subobject with the U-bit set. Identifier ERO subobject with the U-bit set.
o Two Component Interface Identifier ERO subobjects with the same
o) Two Component Interface Identifier ERO subobjects with the same
U-bit values exist. U-bit values exist.
If a node implements the component interface identifier subobject, it If a node implements the component interface identifier subobject, it
must check if it represents a component interface in the bundled TE MUST check if it represents a component interface in the bundled TE
Link specified in the preceding subobject that contains the IPv4/IPv6 Link specified in the preceding subobject that contains the IPv4/IPv6
address or interface identifier of the TE Link. If the content of the address or interface identifier of the TE Link. If the content of the
component interface identifier subobject does not match a component component interface identifier subobject does not match a component
Component Link Record. & Resource Control for TE Link Bundles Mar.2008
interface in the TE link, a "Bad EXPLICIT_ROUTE object" error SHOULD interface in the TE link, a "Bad EXPLICIT_ROUTE object" error SHOULD
be reported as "Routing Problem" (error code 24). be reported as "Routing Problem" (error code 24).
Zamfir, A., Ali, Z., Papadimitriou, D
draft-ietf-mpls-explicit-resource-control-bundle-02.txt Feb. 2006
If U-bit of the subobject being examined is cleared (0) and the If U-bit of the subobject being examined is cleared (0) and the
upstream interface specified in this subobject is acceptable, then upstream interface specified in this subobject is acceptable, then
the value of the upstream component interface is translated locally the value of the upstream component interface is translated locally
in the TLV of the IF_ID RSVP HOP object [RFC 3471]. The local in the TLV of the IF_ID RSVP HOP object [RFC 3471]. The local
decision normally used to select the upstream component link is decision normally used to select the upstream component link is
bypassed except for local translation into the outgoing interface bypassed except for local translation into the outgoing interface
identifier from the received incoming remote interface identifier. If identifier from the received incoming remote interface identifier. If
this interface is not acceptable, a "Bad EXPLICIT_ROUTE object" error this interface is not acceptable, a "Bad EXPLICIT_ROUTE object" error
SHOULD be reported as "Routing Problem" (error code 24). SHOULD be reported as "Routing Problem" (error code 24).
skipping to change at page 8, line 34 skipping to change at page 8, line 38
normally used to select the upstream component link is bypassed normally used to select the upstream component link is bypassed
except for local translation into the outgoing interface identifier except for local translation into the outgoing interface identifier
from the received incoming remote interface identifier. from the received incoming remote interface identifier.
The IF_ID RSVP_HOP object constructed as above MUST be included in The IF_ID RSVP_HOP object constructed as above MUST be included in
the corresponding outgoing Path message. the corresponding outgoing Path message.
Note that, associated with a TE Link sub-object in the ERO, either Note that, associated with a TE Link sub-object in the ERO, either
the (remote) upstream component interface or the (remote) downstream the (remote) upstream component interface or the (remote) downstream
component interface or both may be specified. As specified in component interface or both may be specified. As specified in
[BUNDLE] there is no relationship between the TE Link type (numbered [RFC4201] there is no relationship between the TE Link type (numbered
or unnumbered) and the Link type of any one of its components. or unnumbered) and the Link type of any one of its components.
The component interface identifier ERO subobject is optional. The Component Interface Identifier ERO subobject is optional.
Similarly, presence of the Label ERO sub-objects is not mandatory Similarly, presence of the Label ERO sub-objects is not mandatory
[RFC 3471], [RFC 3473]. Furthermore, component interface identifier [RFC 3471], [RFC 3473]. Furthermore, component interface identifier
ERO subobject and Label ERO subobject may be included in the ERO ERO subobject and Label ERO subobject may be included in the ERO
independently of each other. One of the following alternatives independently of each other. One of the following alternatives
applies: 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 o) When both sub-objects are absent, a node may select any
component link. appropriate component link within the TE link and any label on the
o When the Label subobject is only present for a bundled link, then selected component link.
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 the selection of the component link within the bundle is a local
decision and the node may select any appropriate component link, decision and the node may select any appropriate component link,
which can assume the label specified in the Label ERO. 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
Zamfir, A., Ali, Z., Papadimitriou, D Component Link Record. & Resource Control for TE Link Bundles Mar.2008
draft-ietf-mpls-explicit-resource-control-bundle-02.txt Feb. 2006
ERO and may select any appropriate label value at the specified o) When only the component interface identifier ERO subobject is
component link. present, a node MUST select the component interface specified in
o When both component interface identifier ERO subobject and Label 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 locally ERO subobject are present, the node MUST select the locally
corresponding component link and the specified label value on that corresponding component link and the specified label value on that
component link. When present, both subobjects may appear in any component link. When present, both subobjects may appear in any
relative order to each other but they MUST appear after the TE Link relative order to each other but they MUST appear after the TE
sub-object that they refer to. Link subobject that they refer to.
After processing, the component interface identifier subobjects are After processing, the component interface identifier subobjects are
removed from the ERO. removed from the ERO.
Inferred from above, the interface subobject should never be the Inferred from above, the interface subobject should never be the
first subobject in a newly received message. If the component first subobject in a newly received message. If the component
interface subobject is the first subobject in a received ERO, then it interface subobject is the first subobject in a received ERO, then it
SHOULD be treated as a "Bad strict node" error. SHOULD be treated as a "Bad strict node" error.
Note: Information to construct the Component Interface ERO subobject Note: Information to construct the Component Interface ERO subobject
skipping to change at page 9, line 41 skipping to change at page 9, line 45
The extensions specified in this draft do not affect the processing 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 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 not support the Component Interface RRO subobject but that does
support Label subobject SHOULD only insert the Label subobject in the support Label subobject SHOULD only insert the Label subobject in the
RRO as per [RFC3471] and [RFC3473]. RRO as per [RFC3471] and [RFC3473].
A node that receives an ERO that contains a Component Link ID A node that receives an ERO that contains a Component Link ID
subobject SHOULD send "Bad EXPLICIT_ROUTE object" if it does not subobject SHOULD send "Bad EXPLICIT_ROUTE object" if it does not
implement this subobject. implement this subobject.
As per [RFC3209], Section 4.4.5, a non-compliant node that receives Per [RFC3209], Section 4.4.5, a non-compliant node that receives an
an RRO that contains Component Interface Identifier sub-objects RRO that contains Component Interface Identifier sub-objects should
should ignore and pass them on. This limits the full applicability of ignore and pass them on. This limits the full applicability of if
if nodes traversed by the LSP are compliant with the proposed nodes traversed by the LSP are compliant with the proposed
extensions. extensions.
6. Security Considerations 6. Security Considerations
This document does not introduce new security issues. The security This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC2205] considerations pertaining to the original RSVP protocol [RFC2205]
remain relevant. remain relevant.
Zamfir, A., Ali, Z., Papadimitriou, D Component Link Record. & Resource Control for TE Link Bundles Mar.2008
draft-ietf-mpls-explicit-resource-control-bundle-02.txt Feb. 2006
7. IANA Considerations 7. IANA Considerations
Type of Component Interface Identifier ERO subobject needs to be This document introduces the following RSVP protocol elements:
assigned.
8. Intellectual Property Considerations o) Component Interface Identifier RRO subobject of the Record Route
Object (RRO). The following Types are defined:
The IETF takes no position regarding the validity or scope of any Type 10 (TBD): Component Interface identifier IPv4
Intellectual Property Rights or other rights that might be claimed to Type 11 (TBD): Component Interface identifier IPv6
pertain to the implementation or use of the technology described in Type 12 (TBD): Component Interface identifier Unnumbered
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any o) Component Interface Identifier subobject of the Explicit Route
assurances of licenses to be made available, or the result of an Object (ERO). The following Types are defined:
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Type 10 (TBD): Component Interface identifier IPv4
copyrights, patents or patent applications, or other proprietary Type 11 (TBD): Component Interface identifier IPv6
rights that may cover technology that may be required to implement Type 12 (TBD): Component Interface identifier Unnumbered
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
9. References o) A new "Component Link Recording desired" flag (value TBD)
of the LSP_ATTRIBUTES object [RFC4420]
9.1 Normative Reference 8. References
[RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1, 8.1 Normative Reference
Functional Specification", RFC 2205, Braden, et al, September
1997. [RFC2205] R. Braden, et al., "Resource ReSerVation Protocol (RSVP)
[RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, - Version 1, Functional Specification", RFC 2205,
September 1997.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3209] D. Awduche, et al., "Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001. RFC 3209, December 2001.
[BUNDLE] "Link Bundling in MPLS Traffic Engineering", draft-ietf-
mpls-bundle-05.txt, K. Kompella, et al, January 2003.
[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 3473, L. Berger, et al, January 2003.
Zamfir, A., Ali, Z., Papadimitriou, D [RFC3471] L. Berger, et al., "Generalized Multi-Protocol Label
draft-ietf-mpls-explicit-resource-control-bundle-02.txt Feb. 2006 Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3477] "Signaling Unnumbered Links in Resource ReSerVation [RFC3473] L. Berger, et al., "Generalized Multi-Protocol Label
Protocol - Traffic Engineering (RSVP-TE) ", RFC 3477, K. Kompella, Switching (GMPLS) Signaling Resource ReserVation
Y. Rekhter, January 2003. Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 3473, January 2003.
RFC 2119, S. Bradner, March 1997.
9.2 Informative Reference [RFC3477] K. Kompella, et al., "Signaling Unnumbered Links in
Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RSVP-TE-ATTRIBUTE] "Encoding of Attributes for Multiprotocol Label Component Link Record. & Resource Control for TE Link Bundles Mar.2008
Switching (MPLS) Label Switched Path (LSP) Establishment Using
RSVP-TE", draft-farrel-rsvpte-attributes-00.txt., A. Farrel.
10. Author's Addresses [RFC4201] K. Kompella, et al., "Link Bundling in MPLS Traffic
Engineering", RFC 4201, January 2003.
[RFC4420] A. Farrel, et al., "Encoding of Attributes for
Multiprotocol Label Switching (MPLS) Label Switched Path
(LSP) Establishment Using Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
8.2 Informative Reference
[RFC3945] E. Mannie, et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
9. Author's Addresses
Anca Zamfir Anca Zamfir
Cisco Systems Inc. Cisco Systems Inc.
2000 Innovation Dr., 2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada. Canada.
Phone: (613)-254-3484 Phone: (613)-254-3484
Email: ancaz@cisco.com Email: ancaz@cisco.com
Zafar Ali Zafar Ali
Cisco Systems Inc. Cisco Systems Inc.
2000 Innovation Dr., 2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada. Canada.
Phone: (613) 889-6158 Phone: (613) 889-6158
Email: zali@cisco.com Email: zali@cisco.com
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou
Fr. Wellesplein 1, Alcatel-Lucent
B-2018 Antwerpen, Belgium Copernicuslaan 50
B-2018 Antwerpen
Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be Email: dimitri.papadimitriou@alcatel-lucent.be
11. Full Copyright Statement Component Link Record. & Resource Control for TE Link Bundles Mar.2008
Copyright (C) The Internet Society (2006). This document is subject 10. Full Copyright Statement
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zamfir, A., Ali, Z., Papadimitriou, D 11. Intellectual Property
draft-ietf-mpls-explicit-resource-control-bundle-02.txt Feb. 2006
Zamfir, A., Ali, Z., Papadimitriou, D The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 76 change blocks. 
180 lines changed or deleted 191 lines changed or added

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