draft-ietf-ccamp-lsp-hierarchy-bis-00.txt   draft-ietf-ccamp-lsp-hierarchy-bis-01.txt 
Network Working Group K. Shiomoto(NTT) Network Working Group K. Shiomoto(NTT)
Internet Draft R. Rabbat(Fujitsu) Internet Draft R. Rabbat(Fujitsu)
Updates: 3477, 4206 A. Ayyangar(Juniper Networks) 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: October 2006 April 19, 2006 Expires: April 2007 October 27, 2006
Procedures for Dynamically Signaled Hierarchical Label Switched Paths Procedures for Dynamically Signaled Hierarchical Label Switched Paths
draft-ietf-ccamp-lsp-hierarchy-bis-00.txt draft-ietf-ccamp-lsp-hierarchy-bis-01.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.
This document may only be posted in an Internet-Draft.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. other 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/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 October 19, 2006. This Internet-Draft will expire on April 27, 2007.
Abstract Abstract
This document addresses 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 Routing Adjacency (RA). In
addition, the document also addresses 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 instance
that should be used. 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.................................6 1.5. Contents of This Document.................................7
2. Proposed Solution..............................................7 2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.....7
2.1. IGP Instance Identification...............................8 3. Proposed Solution..............................................7
2.2. LSP advertisement and Usage Identification................8 3.1. IGP Instance Identification...............................8
2.3. LSP_TUNNEL_INTERFACE_ID Object............................8 3.2. LSP advertisement and Usage Identification................9
2.3.1. Unnumbered link......................................9 3.3. LSP_TUNNEL_INTERFACE_ID Object............................9
2.3.2. IPv4 numbered link...................................9 3.3.1. Unnumbered link......................................9
2.3.3. IPv6 numbered link..................................11 3.3.2. IPv4 numbered link..................................10
2.3.4. Unnumbered link with target IGP instance identifier.11 3.3.3. IPv6 numbered link..................................11
2.3.5. Message Formats.....................................12 3.3.4. Unnumbered link with target IGP instance identifier.12
2.4. LSA advertisement........................................12 3.3.5. Message Formats.....................................13
3. Applicability Statement.......................................13 3.4. LSA advertisement........................................13
4. Backward Compatibility Considerations.........................13 4. Applicability Statement.......................................14
5. Security Considerations.......................................13 5. Backward Compatibility Considerations.........................14
6. IANA Considerations...........................................14 6. Security Considerations.......................................14
7. Acknowledgement...............................................14 7. IANA Considerations...........................................15
8. References....................................................14 8. Acknowledgement...............................................15
8.1. Normative References.....................................14 9. References....................................................15
8.2. Informative References...................................15 9.1. Normative References.....................................15
Author's Addresses...............................................15 9.2. Informative References...................................16
Intellectual Property Statement..................................16 Author's Addresses...............................................16
Disclaimer of Validity...........................................16 Intellectual Property Statement..................................17
Copyright Statement..............................................17 Disclaimer of Validity...........................................17
Copyright Statement..............................................18
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 7, line 10 skipping to change at page 7, line 17
This document provides a consolidated way of exchanging TE link This document provides a consolidated way of exchanging TE link
identifiers when an LSP is established through signaling. It also identifiers when an LSP is established through signaling. It also
provides a mechanism to allow the ingress to control whether, and provides a mechanism to allow the ingress to control whether, and
into which IGP instances, an LSP is advertised as an FA and/ or RA by into which IGP instances, an LSP is advertised as an FA and/ or RA by
the egress. The proposed mechanism applies equally to Hierarchical the egress. The proposed mechanism applies equally to Hierarchical
LSPs (H-LSPs) and Stitchable LSPs (S-LSPs). LSPs (H-LSPs) and Stitchable LSPs (S-LSPs).
The method described below extends the method described in [RFC3477], The method described below extends the method described in [RFC3477],
which is applied for an FA-LSP represented as an unnumbered TE link. which is applied for an FA-LSP represented as an unnumbered TE link.
2. Proposed Solution 2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00
o Fixed page formatting
o Updated author addresses
o Readability fixes
3. Proposed Solution
The following method allows the ingress and egress LSRs to exchange The following method allows the ingress and egress LSRs to exchange
the link addresses or link identifiers (including the node ID) of the the link addresses or link identifiers (including the node ID) of the
ends of a numbered or unnumbered TE link to be formed from an LSP. ends of a numbered or unnumbered TE link to be formed from an LSP.
It is an extension of the procedures defined in [RFC3477] for It is an extension of the procedures defined in [RFC3477] for
unnumbered TE links. unnumbered TE links.
If an Ingress LSR, that originates an LSP, intends to advertise this If an Ingress LSR that originates an LSP, intends to advertise this
LSP as a TE link in IS-IS or OSPF [RFC4206], the Ingress LSR MUST LSP as a TE link in IS-IS or OSPF [RFC4206], the Ingress LSR MUST
allocate an address or identifier to the TE link (just like for any allocate an address or identifier to the TE link (just like for any
other TE link), and it MUST do this before the LSP setup request is other TE link), and it MUST do this before the LSP setup request is
signaled. Moreover, the Path message used for establishing the LSP signaled. Moreover, the Path message used for establishing the LSP
that will be used to form the TE link MUST contain the that will be used to form the TE link MUST contain the
LSP_TUNNEL_INTERFACE_ID object (as extended and described below), LSP_TUNNEL_INTERFACE_ID object (as extended and described below),
with the interface address or identifier allocated by the Ingress LSR. with the interface address or identifier allocated by the Ingress LSR.
If the Path message for the H-LSP/S-LSP contains the If the Path message for the H-LSP/S-LSP contains the
LSP_TUNNEL_INTERFACE_ID object, then the Egress LSR (assuming it LSP_TUNNEL_INTERFACE_ID object, then the Egress LSR (assuming it
skipping to change at page 8, line 5 skipping to change at page 8, line 20
Once the Egress LSR has successfully sent a Resv message as described Once the Egress LSR has successfully sent a Resv message as described
above it SHOULD advertise the LSP as a TE link using the above it SHOULD advertise the LSP as a TE link using the
addresses/identifiers exchanged. Once the Resv has been processed by addresses/identifiers exchanged. Once the Resv has been processed by
the Ingress LSR and the LSP has been successfully established, the the Ingress LSR and the LSP has been successfully established, the
Ingress LSR SHOULD advertise the LSP as a TE link using the Ingress LSR SHOULD advertise the LSP as a TE link using the
addresses/identifiers exchanged. addresses/identifiers exchanged.
Once the TE link advertisement has been flooded it is available for Once the TE link advertisement has been flooded it is available for
use in path computation and LSP signaling just like any other TE link. use in path computation and LSP signaling just like any other TE link.
2.1. IGP Instance Identification 3.1. IGP Instance Identification
The mechanism described so far allows an Ingress LSR to indicate that The mechanism described so far allows an Ingress LSR to indicate that
an LSP is to be used as a TE link and allows the Ingress and Egress an LSP is to be used as a TE link and allows the Ingress and Egress
LSRs to exchange addresses or identifiers for that TE link, during LSRs to exchange addresses or identifiers for that TE link, during
LSP setup. LSP setup.
However, it is also necessary to indicate into which instance of the However, it is also necessary to indicate into which instance of the
IGP the advertisement should be made. This is only necessary if the IGP the advertisement should be made. This is only necessary if the
LSP is to be advertised as a TE link into a different instance of the LSP is to be advertised as a TE link into a different instance of the
IGP, and the default behavior may safely be left with the LSP IGP, and the default behavior may safely be left with the LSP
skipping to change at page 8, line 34 skipping to change at page 9, line 5
Once these numbers have been assigned, they MAY be signaled as Once these numbers have been assigned, they MAY be signaled as
additional information in the LSP_TUNNEL_INTERFACE_ID object to additional information in the LSP_TUNNEL_INTERFACE_ID object to
indicate to which instance of the IGP the object applies. indicate to which instance of the IGP the object applies.
The IGP instance identifier value of 0xffffffff is reserved to The IGP instance identifier value of 0xffffffff is reserved to
indicate that the TE link SHOULD be advertised into the same instance indicate that the TE link SHOULD be advertised into the same instance
of the IGP as was used to establish the LSP. Similarly, absence of of the IGP as was used to establish the LSP. Similarly, absence of
the IGP instance identifier means that an FA is to be established (in the IGP instance identifier means that an FA is to be established (in
the same IGP instance). the same IGP instance).
2.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.
2.3. LSP_TUNNEL_INTERFACE_ID Object 3.3. 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 21 skipping to change at page 9, line 39
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.
2.3.1. Unnumbered link 3.3.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 9, line 43 skipping to change at page 10, line 14
when C-Type 1 is used, the TE link SHOULD be advertised only into the when C-Type 1 is used, the TE link SHOULD be advertised only into the
same instance of the IGP as was used to create the LSP. That is, the same instance of the IGP as was used to create the LSP. That is, the
use of C-Type 1 is unchanged from [RFC3477] and is used to create an use of C-Type 1 is unchanged from [RFC3477] and is used to create an
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.
Only one instance of this object with C-Type 1 may be present on a A Path or Resv message MUST have only one instance of this object
Path or Resv message. with C-Type 1.
2.3.2. IPv4 numbered link 3.3.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
skipping to change at page 11, line 5 skipping to change at page 11, line 28
nor MPLS topology. 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.
2.3.3. IPv6 numbered link 3.3.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 11, line 38 skipping to change at page 12, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
2.3.4. Unnumbered link with target IGP instance identifier 3.3.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
skipping to change at page 12, line 26 skipping to change at page 13, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
2.3.5. Message Formats 3.3.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.
2.4. LSA advertisement 3.4. 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 13, line 21 skipping to change at page 14, line 21
The link interface addresses or link interface identifiers for the The link interface addresses or link interface identifiers for the
forward and reverse direction links are taken from the forward and reverse direction links are taken from the
LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages
respectively. respectively.
Address overlap checking for these objects MUST be turned off when Address overlap checking for these objects MUST be turned off when
the LSA is advertised into a IGP instance different from the one used the LSA is advertised into a IGP instance different from the one used
to establish the LSP because the addresses MAY be allocated in both to establish the LSP because the addresses MAY be allocated in both
domains. domains.
3. Applicability Statement 4. Applicability Statement
The method is applicable for both hierarchical LSPs [RFC4206] and LSP The method is applicable for both hierarchical LSPs [RFC4206] and LSP
stitching [STITCH]. stitching [STITCH].
4. Backward Compatibility Considerations 5. Backward Compatibility Considerations
The method does not impact the method to exchange unnumbered FA The method does not impact the method to exchange unnumbered FA
information described in [RFC3477]. That mechanism can be safely information described in [RFC3477]. That mechanism can be safely
used in combination with the new mechanisms described here and is used in combination with the new mechanisms described here and is
functionally equivalent to using the new C-Type indicating an functionally equivalent to using the new C-Type indicating an
unnumbered link with target IGP instance identifier with the Target unnumbered link with target IGP instance identifier with the Target
IGP Instance value set to 0xffffffff. IGP Instance value set to 0xffffffff.
This method obsoletes the method to exchange the numbered FA This method obsoletes the method to exchange the numbered FA
information described in [RFC4206]. This is not believed to be an information described in [RFC4206]. This is not believed to be an
issue as an informal survey indicated that dynamically signaled issue as an informal survey indicated that dynamically signaled
numbered FAs had not been deployed. Indeed it was the attempt to numbered FAs had not been deployed. Indeed it was the attempt to
implement numbered FAs that gave rise to the work on this document. implement numbered FAs that gave rise to the work on this document.
5. Security Considerations 6. Security Considerations
[RFC3477] points out that one can argue that the use of the extra [RFC3477] points out that one can argue that the use of the extra
interface identifier that it provides could make an RSVP message interface identifier that it provides could make an RSVP message
harder to spoof. In that respect, the minor extensions to the harder to spoof. In that respect, the minor extensions to the
protocol made in this document do not constitute an additional protocol made in this document do not constitute an additional
security risk, but could also be said to improve security. security risk, but could also be said to improve security.
It should be noted that the ability of an ingress LSR to request that It should be noted that the ability of an ingress LSR to request that
an egress LSR advertise an LSP as a TE link MUST be subject to an egress LSR advertise an LSP as a TE link MUST be subject to
appropriate policy checks at the egress LSR. That is, the egress LSR appropriate policy checks at the egress LSR. That is, the egress LSR
MUST NOT automatically accept the word of the ingress unless it is MUST NOT automatically accept the word of the ingress unless it is
configured with such a policy. configured with such a policy.
6. 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.
7. Acknowledgement 8. Acknowledgement
The authors would like to thank John Drake for valuable discussions The authors would like to thank John Drake for valuable discussions
and comments. 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.
8. References 9. References
8.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 Y. Rekhter, "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.
[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).
8.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
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630, September
2003. 2003.
[RFC4204] Lang, J. (Ed.), "Link Management Protocol (LMP)", RFC [RFC4204] Lang, J. (Ed.), "Link Management Protocol (LMP)", RFC
4204, October 2005. 4204, October 2005.
[MLN] Shiomoto, K., et al, " Requirements for GMPLS-based multi- [MLN] Shiomoto, K., et al, " Requirements for GMPLS-based multi-
region and multi-layer networks (MRN/MLN)", draft-ietf- region and multi-layer networks (MRN/MLN)", draft-ietf-
skipping to change at page 15, line 34 skipping to change at page 16, line 34
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 Fujitsu Laboratories of America
1240 East Arques Ave, MS 345 1240 East Arques Ave, MS 345
Sunnyvale, CA 94085 Sunnyvale, CA 94085
United States of America United States of America
Phone: +1 408-530-4537 Phone: +1 408-530-4537
Email: richard@us.fujitsu.com Email: rabbat@alum.mit.edu
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Nuova Systems
1194 N. Mathilda Ave. 2600 San Tomas Expressway
Sunnyvale, CA 94089 Santa Clara, CA 95051
United States of America Email: arthi@nuovasystems.com
Phone:
Email: arthi@juniper.net
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Zafar Alli Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada.
EMail: zali@cisco.com EMail: zali@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 16, line 48 skipping to change at page 18, line 4
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 Disclaimer of Validity
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)
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 33 change blocks. 
65 lines changed or deleted 74 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/