draft-ietf-ccamp-lsp-hierarchy-bis-01.txt   draft-ietf-ccamp-lsp-hierarchy-bis-02.txt 
Network Working Group K. Shiomoto (NTT) Network Working Group K. Shiomoto (NTT)
Internet Draft R. Rabbat (Fujitsu) Internet Draft R. Rabbat (Google)
Updates: 3477, 4206 A. Ayyangar (Nuova Systems) Updates: 3477, 4206 A. Ayyangar (Nuova Systems)
Proposed Category: Proposed Standard A. Farrel (Old Dog Consulting) Proposed Category: Proposed Standard A. Farrel (Old Dog Consulting)
Z. Ali (Cisco Systems, Inc.) Z. Ali (Cisco Systems, Inc.)
Expires: April 2007 October 27, 2006 Expires: October 2007 April 26, 2007
Procedures for Dynamically Signaled Hierarchical Label Switched Paths Procedures for Dynamically Signaled Hierarchical Label Switched Paths
draft-ietf-ccamp-lsp-hierarchy-bis-01.txt draft-ietf-ccamp-lsp-hierarchy-bis-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any 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 aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 27, 2007. This Internet-Draft will expire on October 26, 2007.
Abstract Abstract
This document discusses topics related to hierarchical and stitched This document discusses topics related to hierarchical and stitched
Generalized Multiprotocol Label Switching (GMPLS) Label Switched Generalized Multiprotocol Label Switching (GMPLS) Label Switched
Paths (LSPs). It describes extensions to allow an egress to identify Paths (LSPs). It describes extensions to allow an egress to identify
that a bi-directional LSP will be used as a dynamically signaled that a bi-directional LSP will be used as a dynamically signaled
Forwarding Adjacency LSP (FA-LSP) or Routing Adjacency (RA). In Forwarding Adjacency LSP (FA-LSP) or as a Routing Adjacency (RA). In
addition, the document also discusses the issue of how to indicate addition, the document also discusses the issue of how to indicate
that an LSP should be advertised as a traffic engineering (TE) link that an LSP should be advertised as a traffic engineering (TE) link
into a different instance of the IGP and how to identify the instance into a different instance of the IGP, and how to identify the
that should be used. instance that should be used.
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction and Problem Statement.............................3 1. Introduction and Problem Statement.............................3
1.1. LSP Hierarchy.............................................3 1.1. LSP Hierarchy.............................................3
1.2. LSP advertisement and Usage...............................4 1.2. LSP advertisement and Usage...............................4
1.3. Problem Statement.........................................4 1.3. Problem Statement.........................................4
1.4. Current Approaches and Shortcomings.......................6 1.4. Current Approaches and Shortcomings.......................6
1.5. Contents of This Document.................................7 1.5. Contents of This Document.................................7
2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.....7 2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.....7
3. Proposed Solution..............................................7 3. Proposed Solution..............................................7
3.1. IGP Instance Identification...............................8 3.1. IGP Instance Identification...............................8
3.2. LSP advertisement and Usage Identification................9 3.2. LSP advertisement and Usage Identification................9
3.3. LSP_TUNNEL_INTERFACE_ID Object............................9 3.3. Bundling..................................................9
3.3.1. Unnumbered link......................................9 3.4. LSP_TUNNEL_INTERFACE_ID Object...........................10
3.3.2. IPv4 numbered link..................................10 3.4.1. Unnumbered link.....................................10
3.3.3. IPv6 numbered link..................................11 3.4.2. IPv4 numbered link..................................11
3.3.4. Unnumbered link with target IGP instance identifier.12 3.4.3. IPv6 numbered link..................................12
3.3.5. Message Formats.....................................13 3.4.4. Unnumbered link with target IGP instance identifier.13
3.4. LSA advertisement........................................13 3.4.5. Message Formats.....................................13
4. Applicability Statement.......................................14 3.5. TLVs.....................................................14
5. Backward Compatibility Considerations.........................14 3.5.1. Unnumbered Component Link Identifier................14
6. Security Considerations.......................................14 3.5.2. IPv4 Numbered Component Link Identifier.............15
7. IANA Considerations...........................................15 3.6. LSA advertisement........................................15
8. Acknowledgement...............................................15 4. Applicability Statement.......................................16
9. References....................................................15 5. Backward Compatibility Considerations.........................16
9.1. Normative References.....................................15 6. Security Considerations.......................................16
9.2. Informative References...................................16 7. IANA Considerations...........................................17
Author's Addresses...............................................16 8. Acknowledgement...............................................17
Intellectual Property Statement..................................17 9. References....................................................17
Disclaimer of Validity...........................................17 9.1. Normative References.....................................17
Copyright Statement..............................................18 9.2. Informative References...................................17
Author's Addresses...............................................18
Intellectual Property Statement..................................18
Copyright Statement..............................................19
1. Introduction and Problem Statement 1. Introduction and Problem Statement
1.1. LSP Hierarchy 1.1. LSP Hierarchy
LSP hierarchy has been developed to improve the scalability of LSP hierarchy has been developed to improve the scalability of
Generalized Multi-Protocol Label Switching (GMPLS) by allowing Label Generalized Multi-Protocol Label Switching (GMPLS) by allowing Label
Switched Paths (LSPs) to be aggregated into a hierarchy of such LSPs Switched Paths (LSPs) to be aggregated into a hierarchy of such LSPs
[RFC4206]. An LSP may be advertised as a traffic engineering (TE) [RFC4206]. An LSP may be advertised as a traffic engineering (TE)
link for use within the same instance of the control plane as was link for use within the same instance of the control plane as was
used to set up the LSP. This TE link is called a Forwarding Adjacency used to set up the LSP. This TE link is called a Forwarding Adjacency
skipping to change at page 4, line 37 skipping to change at page 4, line 37
decision. decision.
1.3. Problem Statement 1.3. Problem Statement
The extensions described in this document are intended for The extensions described in this document are intended for
dynamically signaled bi-directional Forwarding Adjacency LSPs (FA- dynamically signaled bi-directional Forwarding Adjacency LSPs (FA-
LSPs). In particular this document addresses the following points: LSPs). In particular this document addresses the following points:
(1) How to let the egress node know that this bi-directional LSP (1) How to let the egress node know that this bi-directional LSP
needs to be advertised as an FA, or as routing adjacency (RA), needs to be advertised as an FA, or as routing adjacency (RA),
or its only to be used at the Ingress and Egress nodes. or is only for the use of the ingress and egress nodes.
(2) How to identify the routing instance in which such an (2) How to indicate that a new LSP should be treated as part of a
TE link bundle and advertised as part of that bundle.
(3) How to identify the routing instance in which such an
advertisement should happen. advertisement should happen.
We should note that these aspects are equally applicable to both We should note that these aspects are equally applicable to both
numbered and unnumbered TE links. numbered and unnumbered TE links.
In order for the egress of an LSP to be able to advertise the LSP as In order for the egress of an LSP to be able to advertise the LSP as
a TE link it needs to know that such an advertisement is desirable, a TE link it needs to know that such an advertisement is desirable,
and it also needs to know the TE Router ID of the ingress LSR. and it also needs to know the TE Router ID of the ingress LSR.
(Please recall that the Router ID of the other end of the link is set (Please recall that the Router ID of the other end of the link is set
in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA
[RFC3630].) [RFC3630].) If the LSP is to form part of a TE link bundle, the
The mechanism set out in section 1.1 is used for numbered FAs because egress must also know the identity of the bundle.
When the mechanism set out in section 1.1 is used for numbered FAs,
there is no way to carry the TE Router ID of the ingress LSR in the there is no way to carry the TE Router ID of the ingress LSR in the
RSVP signaling message (Path message) and there is no way to indicate RSVP signaling message (Path message) and there is no way to indicate
that the new LSP is to be used as an FA LSP. Therefore the egress LSR that the new LSP is to be used as an FA LSP. Therefore the egress LSR
has to wait to receive the ingress' advertisement of the TE link to has to wait to receive a routing protocol advertisement of the TE
learn that the LSP is to form a TE link and to learn the TE Router ID link flooded by the ingress to learn about the new TE link and to
of the ingress node before it can advertise the FA as described in deduce that the LSP forms that TE link. The egress must learn the TE
Section 1.2. Note further, that in this approach, the egress LSR must Router ID of the ingress node before it can advertise the FA as
search potentially many LSPs every time it receives an advertisement described in Section 1.2. Note further, that in this approach, the
for a new TE link. egress LSR must search potentially many LSPs every time it receives
an advertisement for a new TE link.
[RFC3477] defines a different method for the exchange of information [RFC3477] defines a different method for the exchange of information
in the signaling protocol during the establishment of LSPs that will in the signaling protocol during the establishment of LSPs that will
be advertised as unnumbered TE links. If the LSP_TUNNEL_INTERFACE_ID be advertised as unnumbered TE links. If the LSP_TUNNEL_INTERFACE_ID
object is present, it indicates that the LSP is to be advertised as a object is present, it indicates that the LSP is to be advertised as a
TE link, and it contains the TE Router ID of the ingress LSR. TE link, and it contains the TE Router ID of the ingress LSR. This
However, the LSP_TUNNEL_INTERFACE_ID object cannot be used for mechanism resolves many of the issues listed above, and provides a
numbered FAs as currently defined. solution for unnumbered TE links, however, the
LSP_TUNNEL_INTERFACE_ID object cannot be used for numbered FAs as
currently defined, and so the problem remains for numbered TE links.
Related to the above problem, a few key observations are worth Related to the above problem, a few key observations are worth
noting: noting:
1. The term FA is applicable only when an LSP is created and used as 1. The term FA is applicable only when an LSP is created and used as
a TE link in the same instance of the IGP. [RFC4206] did not a TE link in the same instance of the IGP. [RFC4206] did not
consider scenarios where an LSP is created (and maintained) by one consider scenarios where an LSP is created (and maintained) by one
instance of the IGP, and is used as a (TE) link by another instance of the IGP, and is used as a (TE) link by another
instance of IGP. This leaves open the question of advertising a TE instance of IGP. This leaves open the question of advertising a TE
link into a different instance of the IGP as is needed in multi- link into a different instance of the IGP as is needed in multi-
skipping to change at page 6, line 21 skipping to change at page 6, line 26
4. When an egress checks the address of the advertised TE link to 4. When an egress checks the address of the advertised TE link to
find the LSP sender (Recall step (4) as described in section 1.1), find the LSP sender (Recall step (4) as described in section 1.1),
it must check the Link-ID address of all received TE it must check the Link-ID address of all received TE
advertisements against its own TE Router ID. If it matches its advertisements against its own TE Router ID. If it matches its
own TE Router ID, the egress checks the advertising router ID of own TE Router ID, the egress checks the advertising router ID of
the TE advertisement against the ingress addresses of all LSPs for the TE advertisement against the ingress addresses of all LSPs for
which it is the egress. It is an assertion of the authors that which it is the egress. It is an assertion of the authors that
this method is not scalable due to the amount of processing needed this method is not scalable due to the amount of processing needed
for all the TE Link State Advertisements (LSAs). for all the TE Link State Advertisements (LSAs).
Further, if a set of LSPs are to be bundled into a single TE link
[RFC4201] then not only is it necessary to identify to the egress
that the LSP will be advertised as part of a TE link, it is also
necessary to indicate the identity of the TE link. This identity is
distinct from the identity of the component link. Thus, in this case
an additional identifier needs to be signaled, but none is currently
available.
1.4. Current Approaches and Shortcomings 1.4. Current Approaches and Shortcomings
[RFC3477] provides a mechanism to exchange unnumbered identifiers for [RFC3477] provides a mechanism to exchange unnumbered identifiers for
the TE link during FA-LSP establishment, and this can be used as a the TE link during FA-LSP establishment, and this can be used as a
notification to the egress that the LSP will be used as a TE link. So, notification to the egress that the LSP will be used as a TE link. So,
for unnumbered TE links, there is a well-defined indication available, for unnumbered TE links, there is a well-defined indication available,
and this could be documented and used as a trigger for TE link and this could be documented and used as a trigger for TE link
advertisement by the egress. advertisement by the egress.
The use of unnumbered TE links may be arguably more sensible than The use of unnumbered TE links may be arguably more sensible than
skipping to change at page 9, line 13 skipping to change at page 9, line 23
the same IGP instance). the same IGP instance).
3.2. LSP advertisement and Usage Identification 3.2. LSP advertisement and Usage Identification
As mentioned earlier, the Egress node also needs to know if it needs As mentioned earlier, the Egress node also needs to know if it needs
to create a full routing adjacency or forwarding adjacency or just to create a full routing adjacency or forwarding adjacency or just
need to treat the LSP as a local virtual link. The extensions defined need to treat the LSP as a local virtual link. The extensions defined
in the following also specify the LSP advertisement and usage in the following also specify the LSP advertisement and usage
treatment. treatment.
3.3. LSP_TUNNEL_INTERFACE_ID Object It is not mutually exclusive whether the LSP has routing adjacency
and whether it has forwarding adjacency. The LSP can have both
routing and forwarding adjacency. In this case, the LSP can be used
to carry both pure IP datagram packets and MPLS labeled packets. If
the LSP has only forwarding adjacency, it is used as TE-link to carry
only MPLS labeled packets. If the LSP has only routing adjacency, it
is used as IP link to carry only pure IP datagram packets.
It is mutually exclusive whether the LPS has routing adjacency and
whether it is treated as a local virtual link. Likewise, it is
mutually exclusive whether the LSP has forwarding adjacency and
whether it is treated as a local virtual link.
3.3. Bundling
It is possible to treat LSPs as component links and to bundle them
into a single TE link. However there is currently no way to signal
that an LSP will be used as part of a bundle and to identify the
bundled link to which the LSP is supposed to belong.
Each LSP that is to form a component link is signaled using the
LSP_TUNNEL_INTERFACE_ID object to identify the TE link bundle to
which the LSP will belong. Thus multiple LSPs may be signaled with
the same address/identifier in the LSP_TUNNEL_INTERFACE_ID object.
When the LSP is to form a component link, the LSP_TUNNEL_INTERFACE_ID
object MUST also contain an additional TLV to identify the component
link. This may be a numbered or unnumbered identifier.
Multiple LSPs may be signaled with the same address/identifier in the
LSP_TUNNEL_INTERFACE_ID object.
3.4. LSP_TUNNEL_INTERFACE_ID Object
The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class
number of 193, which designates that a node that does not understand number of 193, which designates that a node that does not understand
the object SHOULD ignore the object but forward it, unexamined and the object SHOULD ignore the object but forward it, unexamined and
unmodified, in all messages resulting from this message. unmodified, in all messages resulting from this message.
[RFC3477] defines one class type to indicate an unnumbered interface [RFC3477] defines one class type to indicate an unnumbered interface
identifier. This document defines three new class types as follows. identifier. This document defines three new class types as follows.
C-Type Meaning Reference C-Type Meaning Reference
skipping to change at page 9, line 39 skipping to change at page 10, line 36
Multiple instances of the LSP_TUNNEL_INTERFACE_ID object with C-Type Multiple instances of the LSP_TUNNEL_INTERFACE_ID object with C-Type
values 2, 3 or 4 MAY appear in any one Path or Resv message, in which values 2, 3 or 4 MAY appear in any one Path or Resv message, in which
case, each MUST have a different value for the Target IGP Instance case, each MUST have a different value for the Target IGP Instance
field. A Path or Resv message MUST NOT contain more than one field. A Path or Resv message MUST NOT contain more than one
instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and if instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and if
such an object is present, other instances of the object with any such an object is present, other instances of the object with any
other C-Type value MUST NOT have Target IGP Instance set to other C-Type value MUST NOT have Target IGP Instance set to
0xffffffff. 0xffffffff.
3.3.1. Unnumbered link 3.4.1. Unnumbered link
The unnumbered link identifier defined by [RFC3477] is not changed by The unnumbered link identifier defined by [RFC3477] is not changed by
this document. Its usage also remains the same. That is, when this document. Its usage also remains the same. That is, when
present in a Path message it indicates that the LSP being established present in a Path message it indicates that the LSP being established
SHOULD be advertised by the egress LSR as a TE link, and that SHOULD be advertised by the egress LSR as a TE link, and that
unnumbered link identifier is the ingress' identifier for the TE link. unnumbered link identifier is the ingress' identifier for the TE link.
Note that since this form of the object does not contain a target IGP Note that since this form of the object does not contain a target IGP
instance identifier it cannot identify a specific instance of the IGP instance identifier it cannot identify a specific instance of the IGP
into which this TE link should be advertised. Similarly, LSP into which this TE link should be advertised. Similarly, LSP
skipping to change at page 10, line 17 skipping to change at page 11, line 17
unnumbered Forwarding Adjacency. unnumbered Forwarding Adjacency.
This object can appear in either a Path message or a Resv message. This object can appear in either a Path message or a Resv message.
In the former case, we call it the "Forward Interface ID" for that In the former case, we call it the "Forward Interface ID" for that
LSP; in the latter case, we call it the "Reverse Interface ID" for LSP; in the latter case, we call it the "Reverse Interface ID" for
the LSP. the LSP.
A Path or Resv message MUST have only one instance of this object A Path or Resv message MUST have only one instance of this object
with C-Type 1. with C-Type 1.
3.3.2. IPv4 numbered link 3.4.2. IPv4 numbered link
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined
to carry an IPv4 numbered interface address and to indicate into to carry an IPv4 numbered interface address and to indicate into
which instance of the IGP the consequent TE link should be advertised. which instance of the IGP the consequent TE link should be advertised.
The format of the object is as shown below. The format of the object is as shown below.
C-NUM = 193, C-Type = 2(TBD by IANA) C-NUM = 193, C-Type = 2(TBD by IANA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Interface Address (32 bits) | | IPv4 Interface Address (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IGP Instance (32 bits) | | Target IGP Instance (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|F| PADDING | |ACTION | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs | | TLVs |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: The R bit is set to indicate the Egress LSR to establish a full ACTION: This field specifies how the LSP advertisement and usage
routing adjacency over this bidirectional LSP. When R bit is set, the treatment. It indicates if the egress LSR needs to create a full
bidirectional LSP is advertised into the IP topology. routing adjacency or forwarding adjacency or just need to treat the
LSP as a local virtual link. It takes the following values:
F: The F bit is set to indicate the Egress LSR to advertise this LSP
into MPLS TE topology.
It is important to note that R and F bits can be set independent of "0000": LSP is an FA and is only advertised into the MPLS-TE topology.
each other. That is, We should note that it assures the backward compatibility with the
method to exchange unnumbered FA information described in [RFC3477].
R = 1, F = 0: LSP is an RA and is only advertised into the IP network. "0001": LSP is an RA and is only advertised into the IP network.
R = 1, F = 1: LSP is an RA and is advertised in both IP and MPLS-TE "0010": LSP is an RA and is advertised in both IP and MPLS-TE
topologies. topologies.
R = 0, F = 1: LSP is an FA and is only advertised into the MPLS-TE "0011": LSP is neither the FA nor RA and is to be used as a local
topology. virtual link. In this case the LSP is advertised neither in IP nor
MPLS topology.
R = 0, F = 0: LSP is neither the FA nor RA and is to be used as a
local virtual link. In this case the LSP is advertised neither in IP
nor MPLS topology.
The Padding MUST be set to zero on transmission, SHOULD be ignored The Padding MUST be set to zero on transmission, SHOULD be ignored
and forwarded unchanged, and SHOULD be ignored on receipt. and forwarded unchanged, and SHOULD be ignored on receipt.
This object can appear in either a Path message or a Resv message. This object can appear in either a Path message or a Resv message.
In the former case, we call it the "Forward Interface Address" for In the former case, we call it the "Forward Interface Address" for
that LSP; in the latter case, we call it the "Reverse Interface that LSP; in the latter case, we call it the "Reverse Interface
Address" for the LSP. Address" for the LSP.
3.3.3. IPv6 numbered link 3.4.3. IPv6 numbered link
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined
to carry an IPv6 numbered interface address and to indicate into to carry an IPv6 numbered interface address and to indicate into
which instance of the IGP the consequent TE link should be advertised. which instance of the IGP the consequent TE link should be advertised.
The format of the object is as shown below. The format of the object is as shown below.
C-NUM = 193, C-Type = 3(TBD by IANA) C-NUM = 193, C-Type = 3(TBD by IANA)
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
skipping to change at page 12, line 19 skipping to change at page 12, line 44
| IPv6 Interface Address (128 bits) | | IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) | | IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) | | IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) | | IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IGP Instance (32 bits) | | Target IGP Instance (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|F| PADDING | |ACTION | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs | | TLVs |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object can optionally appear in either a Path message or a Resv This object can optionally appear in either a Path message or a Resv
message. In the former case, we call it the "Forward Interface message. In the former case, we call it the "Forward Interface
Address" for that LSP; in the latter case, we call it the "Reverse Address" for that LSP; in the latter case, we call it the "Reverse
Interface Address" for the LSP. Interface Address" for the LSP.
3.3.4. Unnumbered link with target IGP instance identifier 3.4.4. Unnumbered link with target IGP instance identifier
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined
to carry an unnumbered interface identifier and to indicate into to carry an unnumbered interface identifier and to indicate into
which instance of the IGP the consequent TE link should be advertised. which instance of the IGP the consequent TE link should be advertised.
This does not deprecate the use of C-Type 1, but extends its utility. This does not deprecate the use of C-Type 1, but extends its utility.
The format of the object is as shown below. The format of the object is as shown below.
C-NUM = 193, C-Type = 4(TBD by IANA) C-NUM = 193, C-Type = 4(TBD by IANA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID | | LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IGP Instance (32 bits) | | Target IGP Instance (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|F| PADDING | |ACTION | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs | | TLVs |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object can optionally appear in either a Path message or a Resv This object can optionally appear in either a Path message or a Resv
message. In the former case, we call it the "Forward Interface ID" message. In the former case, we call it the "Forward Interface ID"
for that LSP; in the latter case, we call it the "Reverse Interface for that LSP; in the latter case, we call it the "Reverse Interface
ID" for the LSP. ID" for the LSP.
3.3.5. Message Formats 3.4.5. Message Formats
[RFC3477] does not state where in the Path message or Resv message [RFC3477] does not state where in the Path message or Resv message
the LSP_TUNNEL_INTERFACE_ID object should be placed. Since [RFC3209] the LSP_TUNNEL_INTERFACE_ID object should be placed. Since [RFC3209]
states that all implementations are to handle all objects received in states that all implementations are to handle all objects received in
any order, this is not a problem. However, it is RECOMMENDED that the any order, this is not a problem. However, it is RECOMMENDED that the
LSP_TUNNEL_INTERFACE_ID object(s) be placed in the Path message LSP_TUNNEL_INTERFACE_ID object(s) be placed in the Path message
immediately after the SENDER_TSPEC object, and in the Resv message immediately after the SENDER_TSPEC object, and in the Resv message
immediately after the FILTER_SPEC object. immediately after the FILTER_SPEC object.
3.4. LSA advertisement 3.5. TLVs
All TLVs of the LSP_TUNNEL_INTERFACE_ID object have the following
format.
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 (16 bits) | Length (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length field contains the total length of the TLV including the
Type and Length fields in bytes A value field whose length is not a
multiple of four MUST be zero-padded so that the TLV is four-byte
aligned.
This document defines two Type values to be used to specify the
component link identifier that the sending LSR has assigned to the
LSP if it forms part of a TE link bundle. The consequent TLV formats
are shown in the next sections.
3.5.1. Unnumbered Component Link 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 = 1 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component Link Identifier (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is present if the signaled LSP is to be used as an
unnumbered component link of a bundled TE link. In this case, the
identifier (numbered or unnumbered) in the main body of the
LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of which
this LSP is a component, and the Component Link Identifier of this
TLV specifies the unnumbered identifier that is assigned to this
component link within the bundle.
This TLV MUST NOT be present in the same instance of the
LSP_TUNNEL_INTERFACE_ID object as a TLV with type 2 (numbered
component link identifier).
3.5.2. IPv4 Numbered Component Link 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 = 2 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is present if the signaled LSP is to be used as a numbered
component link of a bundled TE link. In this case, the identifier
(numbered or unnumbered) in the main body of the
LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of which
this LSP is a component, and the IPv4 Address field of this TLV
specifies the numbered identifier that is assigned to this component
link within the bundle.
This TLV MUST NOT be present in the same instance of the
LSP_TUNNEL_INTERFACE_ID object as a TLV with type 1 (unnumbered
component link identifier).
3.6. LSA advertisement
The ingress and egress LSRs MAY advertise link state associated with The ingress and egress LSRs MAY advertise link state associated with
TE links created as described above. The link state may be TE links created as described above. The link state may be
advertised in either the same IGP instance as used to compute and advertised in either the same IGP instance as used to compute and
signal the path for the LSPs that support the TE links, or another signal the path for the LSPs that support the TE links, or another
IGP instance. In the former case, the address space for the link IGP instance. In the former case, the address space for the link
state MUST be the same as that used to establish the LSPs. In the state MUST be the same as that used to establish the LSPs. In the
latter case, the address space for the link state MAY be different, latter case, the address space for the link state MAY be different,
which means that addresses already allocated in the IGP instance used which means that addresses already allocated in the IGP instance used
to establish the LSPs MAY be used by the advertised TE link without to establish the LSPs MAY be used by the advertised TE link without
skipping to change at page 15, line 18 skipping to change at page 17, line 15
7. IANA Considerations 7. IANA Considerations
This document defines three new C-Types for the This document defines three new C-Types for the
LSP_TUNNEL_INTERFACE_ID object. The C-Types for this object are LSP_TUNNEL_INTERFACE_ID object. The C-Types for this object are
managed by IANA, and IANA is requested to assign values to the new C- managed by IANA, and IANA is requested to assign values to the new C-
Types as tabulated in section 2.2 and described in sections 2.2.2, Types as tabulated in section 2.2 and described in sections 2.2.2,
2.2.3 and 2.2.4. 2.2.3 and 2.2.4.
8. Acknowledgement 8. Acknowledgement
The authors would like to thank John Drake for valuable discussions The authors would like to thank John Drake and Yakov Rekhter for
and comments. their valuable discussions and comments.
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links [RFC3477] Kompella, K. and Rekhter, Y., "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
[RFC4201] Kompella, K., Rekhter, Y., and Berger, L.," Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with [RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
Generalized MPLS TE", RFC 4206, October 2005. Generalized MPLS TE", RFC 4206, October 2005.
[STITCH] Ayyangar, A. and J.P. Vasseur, "Label Switched Path [STITCH] Ayyangar, A. and J.P. Vasseur, "Label Switched Path
Stitching with Generalized MPLS Traffic Engineering", Stitching with Generalized MPLS Traffic Engineering",
draft-ietf-ccamp-lsp-stitching, (work in progress). draft-ietf-ccamp-lsp-stitching, (work in progress).
9.2. Informative References 9.2. Informative References
[RFC3630] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering [RFC3630] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering
skipping to change at page 16, line 29 skipping to change at page 18, line 23
Kohei Shiomoto Kohei Shiomoto
NTT Network Service Systems Laboratories NTT Network Service Systems Laboratories
3-9-11 Midori 3-9-11 Midori
Musashino, Tokyo 180-8585 Musashino, Tokyo 180-8585
Japan Japan
Phone: +81 422 59 4402 Phone: +81 422 59 4402
Email: shiomoto.kohei@lab.ntt.co.jp Email: shiomoto.kohei@lab.ntt.co.jp
Richard Rabbat Richard Rabbat
Fujitsu Laboratories of America Google Inc.
1240 East Arques Ave, MS 345
Sunnyvale, CA 94085
United States of America
Phone: +1 408-530-4537
Email: rabbat@alum.mit.edu Email: rabbat@alum.mit.edu
Arthi Ayyangar Arthi Ayyangar
Nuova Systems Nuova Systems
2600 San Tomas Expressway 2600 San Tomas Expressway
Santa Clara, CA 95051 Santa Clara, CA 95051
Email: arthi@nuovasystems.com Email: arthi@nuovasystems.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
skipping to change at page 17, line 45 skipping to change at page 19, line 23
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org ietf-ipr@ietf.org
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY (THE IETF TRUST)
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007). 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 is subject to the rights, licenses and restrictions This document and the information contained herein are provided on an
contained in BCP 78, and except as set forth therein, the authors "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
retain all their rights. OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 38 change blocks. 
86 lines changed or deleted 191 lines changed or added

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