draft-ietf-ccamp-lsp-hierarchy-bis-02.txt   draft-ietf-ccamp-lsp-hierarchy-bis-03.txt 
Network Working Group K. Shiomoto (NTT) Network Working Group K. Shiomoto (NTT)
Internet Draft R. Rabbat (Google) Internet Draft R. Rabbat (Google)
Updates: 3477, 4206 A. Ayyangar (Nuova Systems) Updates: 3477, 4206 A. Ayyangar (Juniper Networks)
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 2007 April 26, 2007 Expires: August 2008 February 22, 2008
Procedures for Dynamically Signaled Hierarchical Label Switched Paths Procedures for Dynamically Signaled
draft-ietf-ccamp-lsp-hierarchy-bis-02.txt Hierarchical Label Switched Paths
draft-ietf-ccamp-lsp-hierarchy-bis-03.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
Task Force (IETF), its areas, and its working groups. Note that Engineering Task Force (IETF), its areas, and its working groups.
other groups may also distribute working documents as Internet-Drafts. Note that 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
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-
material or to cite them other than as "work in progress." Drafts as reference 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 26, 2007. This Internet-Draft will expire on August 22,2008.
Abstract Abstract
This document discusses topics related to hierarchical and stitched This document discusses topics related to hierarchical and
Generalized Multiprotocol Label Switching (GMPLS) Label Switched stitched Generalized Multiprotocol Label Switching (GMPLS) Label
Paths (LSPs). It describes extensions to allow an egress to identify Switched Paths (LSPs). It describes extensions to allow an
that a bi-directional LSP will be used as a dynamically signaled egress to identify that a bi-directional LSP will be used as a
Forwarding Adjacency LSP (FA-LSP) or as a Routing Adjacency (RA). In dynamically signaled Forwarding Adjacency LSP (FA-LSP) or as a
addition, the document also discusses the issue of how to indicate Routing Adjacency (RA). In addition, the document also discusses
that an LSP should be advertised as a traffic engineering (TE) link the issue of how to indicate that an LSP should be advertised as
into a different instance of the IGP, and how to identify the a traffic engineering (TE) link into a different instance of the
instance that should be used. IGP, and how to identify the 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
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this 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........................................6
1.4. Current Approaches and Shortcomings.......................6 1.4. Current Approaches and Shortcomings.......................8
1.5. Contents of This Document.................................7 1.5. Contents of This Document.................................9
2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.....7 2. Revision history...........................................9
3. Proposed Solution..............................................7 2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.9
3.1. IGP Instance Identification...............................8 2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01.9
3.2. LSP advertisement and Usage Identification................9 2.3. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-02.10
3.3. Bundling..................................................9 3. Proposed Solution..........................................10
3.4. LSP_TUNNEL_INTERFACE_ID Object...........................10 3.1. IGP Instance Identification...............................11
3.4.1. Unnumbered link.....................................10 3.2. LSP advertisement and Usage Identification................11
3.4.2. IPv4 numbered link..................................11 3.3. Bundling.................................................12
3.4.3. IPv6 numbered link..................................12 3.4. LSP_TUNNEL_INTERFACE_ID Object............................12
3.4.4. Unnumbered link with target IGP instance identifier.13 3.4.1. Unnumbered link.........................................13
3.4.5. Message Formats.....................................13 3.4.2. IPv4 numbered link......................................14
3.5. TLVs.....................................................14 3.4.3. IPv6 numbered link......................................15
3.5.1. Unnumbered Component Link Identifier................14 3.4.4. Unnumbered link with target IGP instance identifier......16
3.5.2. IPv4 Numbered Component Link Identifier.............15 3.4.5. Message Formats........................................16
3.6. LSA advertisement........................................15 3.5. TLVs.....................................................17
4. Applicability Statement.......................................16 3.5.1. Unnumbered Component Link Identifier....................17
5. Backward Compatibility Considerations.........................16 3.5.2. IPv4 Numbered Component Link Identifier.................18
6. Security Considerations.......................................16 3.6. LSA advertisement........................................18
7. IANA Considerations...........................................17 4. Applicability Statement.....................................19
8. Acknowledgement...............................................17 5. Backward Compatibility Considerations.......................19
9. References....................................................17 6. Security Considerations.....................................19
9.1. Normative References.....................................17 7. IANA Considerations........................................20
9.2. Informative References...................................17 8. Acknowledgement............................................20
Author's Addresses...............................................18 9. References.................................................20
Intellectual Property Statement..................................18 9.1. Normative References.....................................20
Copyright Statement..............................................19 9.2. Informative References....................................20
Author's Addresses............................................21
Intellectual Property Statement................................22
Copyright Statement...........................................23
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
Switched Paths (LSPs) to be aggregated into a hierarchy of such LSPs Label Switched Paths (LSPs) to be aggregated into a hierarchy of
[RFC4206]. An LSP may be advertised as a traffic engineering (TE) such LSPs [RFC4206]. An LSP may be advertised as a traffic
link for use within the same instance of the control plane as was engineering (TE) link for use within the same instance of the
used to set up the LSP. This TE link is called a Forwarding Adjacency control plane as was used to set up the LSP. This TE link is
(FA), and the LSP is known as an FA-LSP. called a Forwarding Adjacency (FA), and the LSP is known as an
FA-LSP.
[RFC4206] defines the operation as follows for a numbered FA: [RFC4206] defines the operation as follows for a numbered FA:
1. The ingress signals the LSP using a /31 sender address that it 1. The ingress signals the LSP using a /31 sender address that it
allocates as the source address in the signaling message (tunnel allocates as the source address in the signaling message
sender address in the Sender Template object of the Path message), (tunnel sender address in the Sender Template object of the
and targeting the TE router ID of the egress (destination address Path message), and targeting the TE router ID of the egress
in the Sender object of the Path message). (destination address in the Sender object of the Path
message).
2. The egress sets up the LSP using normal procedures and allocating 2. The egress sets up the LSP using normal procedures and
the partner address of the assigned /31 address in the local allocating the partner address of the assigned /31 address in
interface address. the local interface address.
3. The ingress then forms a Forwarding Adjacency (FA) out of that LSP 3. The ingress then forms a Forwarding Adjacency (FA) out of that
by advertising it as a Traffic Engineering (TE) link using the LSP by advertising it as a Traffic Engineering (TE) link using
routing protocol (OSPF/ISIS) and using the /31 address to the routing protocol (OSPF/ISIS) and using the /31 address to
identify the local end of the TE link. identify the local end of the TE link.
4. When the egress receives the TE link advertisement, it checks the 4. When the egress receives the TE link advertisement, it checks
Link-ID address of the TE advertisement against its own TE Router the Link-ID address of the TE advertisement against its own TE
ID. If it matches its own TE Router ID, the egress checks the Router ID. If it matches its own TE Router ID, the egress
advertising router ID of the TE advertisement against the ingress checks the advertising router ID of the TE advertisement
addresses of all LSPs for which it is the egress and finds the against the ingress addresses of all LSPs for which it is the
address match with the advertising router ID of the TE egress and finds the address match with the advertising router
advertisement. ID of the TE advertisement.
5. The egress then advertises the FA LSP as a TE link setting the 5. The egress then advertises the FA LSP as a TE link setting the
advertising TE Router ID in the Link-ID and the partner address of advertising TE Router ID in the Link-ID and the partner
the assigned /31 address in the local interface address. address of the assigned /31 address in the local interface
address.
Nesting of LSPs originated by other LSRs into that LSP can be Nesting of LSPs originated by other LSRs into that LSP can be
achieved by using the label stack construct. achieved by using the label stack construct.
1.2. LSP advertisement and Usage 1.2. LSP advertisement and Usage
There are three different ways in which traffic can be forwarded to There are three different ways in which traffic can be forwarded
an LSP. Similarly, the LSP can be advertised into the IP topology, to
the MPLS TE topology or both, depending on the intended usage.
As GMPLS LSPs can be bidirectional, full routing adjacencies can be There are different ways in which an LSP can be used to carry
established over a bidirectional GMPLS LSP. When an LSP is used as an traffic and potentially advertised as a link by a routing
RA, it is advertised into IP network and can optionally be advertised protocol.
into the MPLS topology. The notion of RA is only applicable to
bidirectional LSPs.
As mentioned above, there is no IGP adjacency over the LSP, when it First, the LSP can be used either as a link inside or outside
is to be used as an FA. FA-LSPs can be advertised into the IP and/ or the network that was used to form the LSP. In the former case,
MPLS topologies. Notion of FA is equally applicable to the the LSP can carry traffic that could have been routed down the
unidirectional as well as bidirectional LSPs. TE links that are navigated by the LSP. In the latter case, it
is used by a client network, which is provided on top of the
network [MLN-REQ]. It can provide a new, virtual, point-to-point
link in a client network. The former case can only be achieved
in packet networks as they are the only type of network that
supports nesting of LSPs within the same technology LSP, but the
latter case is applicable to all client/server network
relationships such as IP over MPLS, or packet over optical.
There are also scenarios where intent of establishing an LSP is to Second, the link formed by the LSP can be advertised by the
use it for traffic local to the Ingress/ Egress LSRs. In this case, routing protocol as available to carry traffic, or can be kept
the LSP is neither advertised into the IP nor in MPLS topologies. In as a private link known only to the head and tail end LSRs.
this document, such LSPs are referred as local virtual links.
Forwarding treatment for a local virtual link is based on a local These two options give rise to four possible combinations as
decision. follows.
1. The LSP is created and advertised as a TE link in the same
instance of the routing protocol as was used to advertise the
links that it traverses. This is a Forwarding Adjacency as
described in [RFC4206]. Note that no routing adjacency is formed
over the LSP.
2. The LSP is created and made available to carry traffic in the
same network as the links that it traverses, but it is not
advertised. The availability of the LSP is private to the end
points. This is a hierarchical LSP, but not an FA. It might be
used for inter-domain traffic engineering [RFC4726].
3. The LSP is created as before, but is advertised as a link in
another instance of the routing protocol. This method of
operation is particular to client/server networks and especially
multi-layer networks [MLN-REQ], [PCE-INTER-LAYER-REQ].
4. An LSP can be created and used by a client network without
being advertised in the client network routing protocol. Just as
in case 2, the existence of the LSP as a protocol tunnel is
known only to the tunnel LSP points which are nodes in the
client network.
Notes:
a. Case 1 includes the multi-layer traffic engineering scenario
where a single instance of the routing protocol is used across
both layers. This situation was particularly envisaged in
[RFC4206].
b. The example cited in case 2 is special because the
hierarchical LSP is edge-to-edge within a particular domain and
no TE links are advertised outside of the domain (by definition
of the domain). The purpose of the TE link is to carry traffic
across the domain and not to carry intra-domain traffic.
Advertising the TE link within the domain might cause internal
traffic to take longer paths as it seeks to use the hierarchical
LSP.
c. Case 3 is not the only option for the multi-layer network as
explained in Note a.
d. The client network in case 3 may be a different technology TE
network (such as a GMPLS TDM network that operates over a GMPLS
WDM network, or an MPLS-TE network operating over a GMPLS
optical network), a same-technology TE network where LSP nesting
is allowed (for example, an MPLS-TE network operating over
another MPLS-TE network), or a non-TE network (such as an IP
network operating over an MPLS-TE or GMPLS network of any
technology). Thus, the link advertised may be a TE link, or a
routing link. In the second instance, the LSP is used to form a
virtual adjacency between two non-neighboring IP routers (a
Routing Adjacency - RA) forming IGP shortcuts.
e. IGP shortcuts are precluded when the LSP end-points reside
within different IGP areas [RFC4105].
f. IGP shortcuts should be treated with extreme caution when
they are created and used in the same IP/MPLS network. Thus, it
may be more common to use them as described in case 4 and even
in this case, only when the egress of the LSP is the final
destination of the traffic carried.
g. It would be unusual although not impossible to use a
hierarchical LSP as an IGP shortcut within the control plane.
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
LSPs). In particular this document addresses the following points: (FA-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
needs to be advertised as an FA, or as routing adjacency (RA), LSP needs to be advertised as an FA, or as an RA, or as an
or is only for the use of the ingress and egress nodes. FA and RA or is a local virtual link only for the use of
the ingress and egress nodes.
(2) How to indicate that a new LSP should be treated as part of a (2) How to indicate that a new LSP should be treated as part of
TE link bundle and advertised as part of that bundle. a TE link bundle and advertised as part of that bundle.
(3) How to identify the routing instance in which such an (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 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. (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 [RFC3630].) If the LSP is to form part of a TE
link bundle, the egress must also know the identity of the
bundle.
In order for the egress of an LSP to be able to advertise the LSP as When the mechanism set out in section 1.1 is used for numbered
a TE link it needs to know that such an advertisement is desirable, FAs, there is no way to carry the TE Router ID of the ingress
and it also needs to know the TE Router ID of the ingress LSR. LSR in the RSVP signaling message (Path message) and there is no
way to indicate that the new LSP is to be used as an FA LSP.
(Please recall that the Router ID of the other end of the link is set Therefore the egress LSR has to wait to receive a routing
in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA protocol advertisement of the TE link flooded by the ingress to
[RFC3630].) If the LSP is to form part of a TE link bundle, the learn about the new TE link and to deduce that the LSP forms
egress must also know the identity of the bundle. that TE link. The egress must learn the TE Router ID of the
ingress node before it can advertise the FA as described in
When the mechanism set out in section 1.1 is used for numbered FAs, Section 1.2. Note further, that in this approach, the egress LSR
there is no way to carry the TE Router ID of the ingress LSR in the must search potentially many LSPs every time it receives an
RSVP signaling message (Path message) and there is no way to indicate advertisement for a new TE link.
that the new LSP is to be used as an FA LSP. Therefore the egress LSR
has to wait to receive a routing protocol advertisement of the TE
link flooded by the ingress to learn about the new TE link and to
deduce that the LSP forms that TE link. The egress must learn the TE
Router ID of the ingress node before it can advertise the FA as
described in Section 1.2. Note further, that in this approach, the
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
in the signaling protocol during the establishment of LSPs that will information in the signaling protocol during the establishment
be advertised as unnumbered TE links. If the LSP_TUNNEL_INTERFACE_ID of LSPs that will be advertised as unnumbered TE links. If the
object is present, it indicates that the LSP is to be advertised as a LSP_TUNNEL_INTERFACE_ID object is present, it indicates that the
TE link, and it contains the TE Router ID of the ingress LSR. This LSP is to be advertised as a TE link, and it contains the TE
mechanism resolves many of the issues listed above, and provides a Router ID of the ingress LSR. This mechanism resolves many of
solution for unnumbered TE links, however, the the issues listed above, and provides a solution for unnumbered
LSP_TUNNEL_INTERFACE_ID object cannot be used for numbered FAs as TE links, however, the LSP_TUNNEL_INTERFACE_ID object cannot be
currently defined, and so the problem remains for numbered TE links. 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 6. The term FA is applicable only when an LSP is created and used
a TE link in the same instance of the IGP. [RFC4206] did not as a TE link in the same instance of the IGP. [RFC4206] did
consider scenarios where an LSP is created (and maintained) by one not consider scenarios where an LSP is created (and
instance of the IGP, and is used as a (TE) link by another maintained) by one instance of the IGP, and is used as a (TE)
instance of IGP. This leaves open the question of advertising a TE link by another instance of IGP. This leaves open the question
link into a different instance of the IGP as is needed in multi- of advertising a TE link into a different instance of the IGP
region/multi-layer networks [MLN], and how to identify which as is needed in multi-region/multi-layer networks [MLN-REQ],
instance of the IGP should be used. In addition, the TE link and how to identify which instance of the IGP should be used.
advertised into the different IGP instance may be associated with In addition, the TE link advertised into the different IGP
an IGP neighbor adjacency. We call it a routing adjacency (RA). instance may be associated with an IGP neighbor adjacency. We
The decision as to whether the link should be advertised to MPLS call it a routing adjacency (RA). The decision as to whether
TE topology or IP topology or both depends on operator policy. the link should be advertised to MPLS TE topology or IP
Therefore, a mechanism to indicate the choice to the Egress node topology or both depends on operator policy. Therefore, a
is needed. mechanism to indicate the choice to the Egress node is needed.
2. [RFC4206] provides a way to exchange numbered identifiers for the 7. [RFC4206] provides a way to exchange numbered identifiers for
TE link, but this does not clearly state that the Ingress node can the TE link, but this does not clearly state that the Ingress
use presence of the LSP_TUNNEL_INTERFACE_ID object as a trigger node can use presence of the LSP_TUNNEL_INTERFACE_ID object as
for TE link advertisement at the egress node. a trigger for TE link advertisement at the egress node.
3. It is important to note that an LSP that is set up in a server 8. It is important to note that an LSP that is set up in a server
GMPLS transport network and advertised as a TE link in a client GMPLS transport network and advertised as a TE link in a
MPLS data network is NOT an FA-LSP according to the definitions client MPLS data network is NOT an FA-LSP according to the
explained in point 1, above. This is the case regardless of definitions explained in point 1, above. This is the case
whether the GMPLS network is packet- or non-packet-capable. regardless of whether the GMPLS network is packet- or non-
packet-capable.
4. When an egress checks the address of the advertised TE link to 9. 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
it must check the Link-ID address of all received TE 1.1), 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
own TE Router ID, the egress checks the advertising router ID of its own TE Router ID, the egress checks the advertising router
the TE advertisement against the ingress addresses of all LSPs for ID of the TE advertisement against the ingress addresses of
which it is the egress. It is an assertion of the authors that all LSPs for which it is the egress. It is an assertion of
this method is not scalable due to the amount of processing needed the authors that this method is not scalable due to the amount
for all the TE Link State Advertisements (LSAs). of processing needed for all the TE Link State Advertisements
(LSAs).
Further, if a set of LSPs are to be bundled into a single TE link 10.Further, if a set of LSPs are to be bundled into a single TE
[RFC4201] then not only is it necessary to identify to the egress link [RFC4201] then not only is it necessary to identify to the
that the LSP will be advertised as part of a TE link, it is also egress that the LSP will be advertised as part of a TE link, it
necessary to indicate the identity of the TE link. This identity is is also necessary to indicate the identity of the TE link. This
distinct from the identity of the component link. Thus, in this case identity is distinct from the identity of the component link.
an additional identifier needs to be signaled, but none is currently Thus, in this case an additional identifier needs to be signaled,
available. 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
the TE link during FA-LSP establishment, and this can be used as a identifiers for the TE link during FA-LSP establishment, and
notification to the egress that the LSP will be used as a TE link. So, this can be used as a notification to the egress that the LSP
for unnumbered TE links, there is a well-defined indication available, will be used as a TE link. So, for unnumbered TE links, there is
and this could be documented and used as a trigger for TE link a well-defined indication available, and this could be
advertisement by the egress. documented and used as a trigger for TE link 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
assigning numbers to FAs, especially in the case of large networks. than assigning numbers to FAs, especially in the case of large
Some operators though prefer to consistently use numbered TE links networks. Some operators though prefer to consistently use
for both static and dynamic (that is, FA) TE links in their networks. numbered TE links for both static and dynamic (that is, FA) TE
In the case of numbered TE links, however, there is no available links in their networks. In the case of numbered TE links,
indication to allow the egress to know that an LSP should be however, there is no available indication to allow the egress to
advertised as a TE link. know that an LSP should be advertised as a TE link.
In addition, using unnumbered TE links does not address the issue of In addition, using unnumbered TE links does not address the
advertising TE links into a different instance of the IGP. There is issue of advertising TE links into a different instance of the
no defined mechanism to identify whether it should be advertised as IGP. There is no defined mechanism to identify whether it should
an FA, a full Routing Adjacency (RA), or a static link. be advertised as an FA, a full Routing Adjacency (RA), or it
should be used as a local virtual link.
The Link Management Protocol (LMP) [RFC4204] could possibly be run on The Link Management Protocol (LMP) [RFC4204] could possibly be
remote adjacencies between the endpoints of an LSP. But LMP peer run on remote adjacencies between the endpoints of an LSP. But
discovery would be required for dynamic LMP peering and is not LMP peer discovery would be required for dynamic LMP peering and
currently specified. In addition, the concept of a remote LMP is not currently specified. In addition, the concept of a
adjacency remains unproven. Lastly, there would be a requirement remote LMP adjacency remains unproven. Lastly, there would be a
that all layers/regions in a MLN network run LMP. This may not be requirement that all layers/regions in a MLN network run LMP.
the case in existing networks and would put undue burden on the This may not be the case in existing networks and would put
network operator to deploy another protocol. undue burden on the network operator to deploy another protocol.
1.5. Contents of This Document 1.5. Contents of This Document
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
provides a mechanism to allow the ingress to control whether, and also provides a mechanism to allow the ingress to control
into which IGP instances, an LSP is advertised as an FA and/ or RA by whether, and into which IGP instances, an LSP is advertised as
the egress. The proposed mechanism applies equally to Hierarchical an FA and/ or RA by the egress. The proposed mechanism applies
LSPs (H-LSPs) and Stitchable LSPs (S-LSPs). equally to Hierarchical 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
which is applied for an FA-LSP represented as an unnumbered TE link. [RFC3477], which is applied for an FA-LSP represented as an
unnumbered TE link.
2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00 2. Revision history
2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00
o Fixed page formatting o Fixed page formatting
o Updated author addresses o Updated author addresses
o Readability fixes o Readability fixes
2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01
o Added indication of bundled link
o Added "ACTION" field, which obsoletes R and F bits
o Readability fixes
2.3. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-02
o Rewrite Section 1.2
o Updated author addresses
o Readability fixes
3. Proposed Solution 3. Proposed Solution
The following method allows the ingress and egress LSRs to exchange The following method allows the ingress and egress LSRs to
the link addresses or link identifiers (including the node ID) of the exchange the link addresses or link identifiers (including the
ends of a numbered or unnumbered TE link to be formed from an LSP. node ID) of the ends of a numbered or unnumbered TE link to be
It is an extension of the procedures defined in [RFC3477] for formed from an LSP. It is an extension of the procedures
unnumbered TE links. defined in [RFC3477] for 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
LSP as a TE link in IS-IS or OSPF [RFC4206], the Ingress LSR MUST this LSP as a TE link in IS-IS or OSPF [RFC4206], the ingress
allocate an address or identifier to the TE link (just like for any LSR MUST allocate an address or identifier to the TE link (just
other TE link), and it MUST do this before the LSP setup request is like for any other TE link), and it MUST do this before the LSP
signaled. Moreover, the Path message used for establishing the LSP setup request is signaled. Moreover, the Path message used for
that will be used to form the TE link MUST contain the establishing the LSP that will be used to form the TE link MUST
LSP_TUNNEL_INTERFACE_ID object (as extended and described below), contain the LSP_TUNNEL_INTERFACE_ID object (as extended and
with the interface address or identifier allocated by the Ingress LSR. described below), 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
accepts the LSP request) MUST allocate an address or identifier to accepts the LSP request) MUST allocate an address or identifier
the TE link that will be formed (just like for any other numbered or to the TE link that will be formed (just like for any other
unnumbered TE link). Furthermore, the Resv message for the LSP MUST numbered or unnumbered TE link). Furthermore, the Resv message
contain an LSP_TUNNEL_INTERFACE_ID object, with the interface address for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with
or identifier allocated by the Egress LSR. the interface address or identifier allocated by the egress LSR.
In all cases where an LSP is to be advertised as a TE link, the In all cases where an LSP is to be advertised as a TE link, the
Tunnel Sender Address in the Sender Template Object of the Path Tunnel Sender Address in the Sender Template Object of the Path
message MUST be set to the TE Router ID of the Ingress LSR. We should message MUST be set to the TE Router ID of the ingress LSR. We
note that this is a change from the method described in [RFC4206]. should note that this is a change from the method described in
[RFC4206].
Once the Egress LSR has successfully sent a Resv message as described Once the egress LSR has successfully sent a Resv message as
above it SHOULD advertise the LSP as a TE link using the described above it SHOULD advertise the LSP as a TE link using
addresses/identifiers exchanged. Once the Resv has been processed by the addresses/identifiers exchanged. Once the Resv has been
the Ingress LSR and the LSP has been successfully established, the processed by the ingress LSR and the LSP has been successfully
Ingress LSR SHOULD advertise the LSP as a TE link using the established, the ingress LSR SHOULD advertise the LSP as a TE
addresses/identifiers exchanged. link using the 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
use in path computation and LSP signaling just like any other TE link. for use in path computation and LSP signaling just like any
other TE link.
3.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
an LSP is to be used as a TE link and allows the Ingress and Egress that an LSP is to be used as a TE link and allows the ingress
LSRs to exchange addresses or identifiers for that TE link, during and egress LSRs to exchange addresses or identifiers for that TE
LSP setup. link, during 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
IGP the advertisement should be made. This is only necessary if the the IGP the advertisement should be made. This is only
LSP is to be advertised as a TE link into a different instance of the necessary if the LSP is to be advertised as a TE link into a
IGP, and the default behavior may safely be left with the LSP different instance of the IGP, and the default behavior may
advertised into the same instance of the IGP (that is, FA behavior). safely be left with the LSP advertised into the same instance of
the IGP.
Indication of the IGP in which the advertisement is to be made first Indication of the IGP in which the advertisement is to be made
requires that a 32-bit identifier be assigned to each of the IGP first requires that a 32-bit identifier be assigned to each of
instances within a network, and that Ingress and Egress LSRs have the the IGP instances within a network, and that ingress and egress
same understanding of these numbers. This is a management LSRs have the same understanding of these numbers. This is a
configuration exercise outside the scope of this document. management configuration exercise outside the scope of this
document.
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
of the IGP as was used to establish the LSP. Similarly, absence of instance of the IGP as was used to establish the LSP. Similarly,
the IGP instance identifier means that an FA is to be established (in absence of the IGP instance identifier means that an FA is to be
the same IGP instance). established (in 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
to create a full routing adjacency or forwarding adjacency or just needs to create a full routing adjacency or forwarding adjacency
need to treat the LSP as a local virtual link. The extensions defined or just need to treat the LSP as a local virtual link. The
in the following also specify the LSP advertisement and usage extensions defined in the following also specify the LSP
treatment. advertisement and usage treatment.
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 It is not mutually exclusive whether the LSP has routing
whether it is treated as a local virtual link. Likewise, it is adjacency and whether it has forwarding adjacency. The LSP can
mutually exclusive whether the LSP has forwarding adjacency and have both routing and forwarding adjacency. In this case, the LSP
whether it is treated as a local virtual link. 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.
Note that the LSP which has only forwarding adjacency is useful
to improve the scalability. Suppose that distant PSC domains are
connected by a set of lower-layer LSPs created in the optical
domain (TDM, LSC, or FSC). We do not require routing adjacency on
all such lower-layer LSPs as long as we have control plane
connectivity through a subset of lower-layer LSPs which have
routing adjacency. We reduce the amount of overhead of IGP
protocol processing on the LSPs which do not have routing
adjacency.
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 3.3. Bundling
It is possible to treat LSPs as component links and to bundle them It is possible to treat LSPs as component links and to bundle
into a single TE link. However there is currently no way to signal them into a single TE link. However there is currently no way to
that an LSP will be used as part of a bundle and to identify the signal that an LSP will be used as part of a bundle and to
bundled link to which the LSP is supposed to belong. 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 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 LSP_TUNNEL_INTERFACE_ID object to identify the TE link bundle to
which the LSP will belong. Thus multiple LSPs may be signaled with which the LSP will belong. Thus multiple LSPs may be signaled
the same address/identifier in the LSP_TUNNEL_INTERFACE_ID object. with the same address/identifier in the LSP_TUNNEL_INTERFACE_ID
When the LSP is to form a component link, the LSP_TUNNEL_INTERFACE_ID object. When the LSP is to form a component link, the
object MUST also contain an additional TLV to identify the component LSP_TUNNEL_INTERFACE_ID object MUST also contain an additional
link. This may be a numbered or unnumbered identifier. 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 Multiple LSPs may be signaled with the same address/identifier
LSP_TUNNEL_INTERFACE_ID object. in the LSP_TUNNEL_INTERFACE_ID object.
3.4. 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
number of 193, which designates that a node that does not understand class number of 193, which designates that a node that does not
the object SHOULD ignore the object but forward it, unexamined and understand the object SHOULD ignore the object but forward it,
unmodified, in all messages resulting from this message. unexamined and 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
identifier. This document defines three new class types as follows. interface identifier. This document defines three new class
types as follows.
C-Type Meaning Reference C-Type Meaning
--------------------------------------------------------------------- Reference
----------------------------------------------------------------
1 Unnumbered interface identifier [RFC3477] 1 Unnumbered interface identifier [RFC3477]
2 (TBD by IANA) IPv4 interface identifier with target 2.2.2 2 (TBD by IANA) IPv4 interface identifier with target 2.2.2
3 (TBD by IANA) IPv6 interface identifier with target 2.2.3 3 (TBD by IANA) IPv6 interface identifier with target 2.2.3
4 (TBD by IANA) Unnumbered interface with target 2.2.4 4 (TBD by IANA) Unnumbered interface with target 2.2.4
Multiple instances of the LSP_TUNNEL_INTERFACE_ID object with C-Type Multiple instances of the LSP_TUNNEL_INTERFACE_ID object with C-
values 2, 3 or 4 MAY appear in any one Path or Resv message, in which Type values 2, 3 or 4 MAY appear in any one Path or Resv message,
case, each MUST have a different value for the Target IGP Instance in which case, each MUST have a different value for the Target
field. A Path or Resv message MUST NOT contain more than one IGP Instance field. A Path or Resv message MUST NOT contain
instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and if more than one instance of the LSP_TUNNEL_INTERFACE_ID object
such an object is present, other instances of the object with any with C-Type 1, and if such an object is present, other instances
other C-Type value MUST NOT have Target IGP Instance set to of the object with any other C-Type value MUST NOT have Target
0xffffffff. IGP Instance set to 0xffffffff.
3.4.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
this document. Its usage also remains the same. That is, when changed by this document. Its usage also remains the same.
present in a Path message it indicates that the LSP being established That is, when present in a Path message it indicates that the
SHOULD be advertised by the egress LSR as a TE link, and that LSP being established SHOULD be advertised by the egress LSR as
unnumbered link identifier is the ingress' identifier for the TE link. a TE link, and that 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
instance identifier it cannot identify a specific instance of the IGP target IGP instance identifier it cannot identify a specific
into which this TE link should be advertised. Similarly, LSP instance of the IGP into which this TE link should be advertised.
advertisement and usage treatment also needs to be specified. Thus, Similarly, LSP advertisement and usage treatment also needs to
when C-Type 1 is used, the TE link SHOULD be advertised only into the be specified. Thus, when C-Type 1 is used, the TE link SHOULD be
same instance of the IGP as was used to create the LSP. That is, the advertised only into the same instance of the IGP as was used to
use of C-Type 1 is unchanged from [RFC3477] and is used to create an create the LSP. That is, the use of C-Type 1 is unchanged from
unnumbered Forwarding Adjacency. [RFC3477] and is used to create an 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
In the former case, we call it the "Forward Interface ID" for that message. In the former case, we call it the "Forward Interface
LSP; in the latter case, we call it the "Reverse Interface ID" for ID" for that LSP; in the latter case, we call it the "Reverse
the LSP. Interface ID" for 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
with C-Type 1. object with C-Type 1.
3.4.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
to carry an IPv4 numbered interface address and to indicate into defined to carry an IPv4 numbered interface address and to
which instance of the IGP the consequent TE link should be advertised. indicate into 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACTION | PADDING | |ACTION | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs | | TLVs |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACTION: This field specifies how the LSP advertisement and usage ACTION: This field specifies how the LSP advertisement and usage
treatment. It indicates if the egress LSR needs to create a full treatment. It indicates if the egress LSR needs to create a full
routing adjacency or forwarding adjacency or just need to treat the routing adjacency or forwarding adjacency or just need to treat
LSP as a local virtual link. It takes the following values: the LSP as a local virtual link. It takes the following values:
"0000": LSP is an FA and is only advertised into the MPLS-TE topology. "0000": LSP is an FA and is only advertised into the MPLS-TE
We should note that it assures the backward compatibility with the topology. We should note that it assures the backward
method to exchange unnumbered FA information described in [RFC3477]. compatibility with the method to exchange unnumbered FA
information described in [RFC3477].
"0001": 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.
"0010": LSP is an RA and FA and is advertised in both IP and
"0010": LSP is an RA and is advertised in both IP and MPLS-TE MPLS-TE topologies.
topologies.
"0011": LSP is neither the FA nor RA and is to be used as a local "0011": 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 virtual link. In this case the LSP is advertised neither in IP
MPLS topology. nor MPLS topology.
The Padding MUST be set to zero on transmission, SHOULD be
The Padding MUST be set to zero on transmission, SHOULD be ignored ignored and forwarded unchanged, and SHOULD be ignored on
and forwarded unchanged, and SHOULD be ignored on receipt. receipt.
This object can appear in either a Path message or a Resv
This object can appear in either a Path message or a Resv message. message. In the former case, we call it the "Forward Interface
In the former case, we call it the "Forward Interface Address" for Address" for that LSP; in the latter case, we call it the
that LSP; in the latter case, we call it the "Reverse Interface "Reverse Interface Address" for the LSP.
Address" for the LSP.
3.4.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
to carry an IPv6 numbered interface address and to indicate into defined to carry an IPv6 numbered interface address and to
which instance of the IGP the consequent TE link should be advertised. indicate into 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 4 skipping to change at page 15, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) | | IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IGP Instance (32 bits) | | Target IGP Instance (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACTION | PADDING | |ACTION | PADDING |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs | | TLVs |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object can optionally appear in either a Path message or a Resv
message. In the former case, we call it the "Forward Interface This object can optionally appear in either a Path message or a
Address" for that LSP; in the latter case, we call it the "Reverse Resv message. In the former case, we call it the "Forward
Interface Address" for the LSP. Interface Address" for that LSP; in the latter case, we call it
the "Reverse Interface Address" for the LSP.
3.4.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
to carry an unnumbered interface identifier and to indicate into defined to carry an unnumbered interface identifier and to
which instance of the IGP the consequent TE link should be advertised. indicate into which instance of the IGP the consequent TE link
This does not deprecate the use of C-Type 1, but extends its utility. should be advertised. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 34 skipping to change at page 16, line 32
| Interface ID (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IGP Instance (32 bits) | | Target IGP Instance (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACTION | 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
message. In the former case, we call it the "Forward Interface ID" Resv message. In the former case, we call it the "Forward
for that LSP; in the latter case, we call it the "Reverse Interface Interface ID" for that LSP; in the latter case, we call it the
ID" for the LSP. "Reverse Interface ID" for the LSP.
3.4.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
the LSP_TUNNEL_INTERFACE_ID object should be placed. Since [RFC3209] message the LSP_TUNNEL_INTERFACE_ID object should be placed.
states that all implementations are to handle all objects received in Since [RFC3209] states that all implementations are to handle
any order, this is not a problem. However, it is RECOMMENDED that the all objects received in any order, this is not a problem.
LSP_TUNNEL_INTERFACE_ID object(s) be placed in the Path message However, it is RECOMMENDED that the LSP_TUNNEL_INTERFACE_ID
immediately after the SENDER_TSPEC object, and in the Resv message object(s) be placed in the Path message immediately after the
immediately after the FILTER_SPEC object. SENDER_TSPEC object, and in the Resv message immediately after
the FILTER_SPEC object.
3.5. TLVs 3.5. TLVs
All TLVs of the LSP_TUNNEL_INTERFACE_ID object have the following All TLVs of the LSP_TUNNEL_INTERFACE_ID object have the
format. following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (16 bits) | Length (16 bits) | | Type (16 bits) | Length (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) | | Value (variable) |
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length field contains the total length of the TLV including the The length field contains the total length of the TLV including
Type and Length fields in bytes A value field whose length is not a the Type and Length fields in bytes A value field whose length
multiple of four MUST be zero-padded so that the TLV is four-byte is not a multiple of four MUST be zero-padded so that the TLV is
aligned. four-byte aligned.
This document defines two Type values to be used to specify the This document defines two Type values to be used to specify the
component link identifier that the sending LSR has assigned to the component link identifier that the sending LSR has assigned to
LSP if it forms part of a TE link bundle. The consequent TLV formats the LSP if it forms part of a TE link bundle. The consequent
are shown in the next sections. TLV formats are shown in the next sections.
3.5.1. Unnumbered Component Link Identifier 3.5.1. Unnumbered Component Link Identifier
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length = 8 | | Type = 1 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component Link Identifier (32 bits) | | Component Link Identifier (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is present if the signaled LSP is to be used as an 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 unnumbered component link of a bundled TE link. In this case,
identifier (numbered or unnumbered) in the main body of the the identifier (numbered or unnumbered) in the main body of the
LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of which LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of
this LSP is a component, and the Component Link Identifier of this which this LSP is a component, and the Component Link Identifier
TLV specifies the unnumbered identifier that is assigned to this of this TLV specifies the unnumbered identifier that is assigned
component link within the bundle. to this component link within the bundle.
This TLV MUST NOT be present in the same instance of the This TLV MUST NOT be present in the same instance of the
LSP_TUNNEL_INTERFACE_ID object as a TLV with type 2 (numbered LSP_TUNNEL_INTERFACE_ID object as a TLV with type 2 (numbered
component link identifier). component link identifier).
3.5.2. IPv4 Numbered Component Link Identifier 3.5.2. IPv4 Numbered Component Link Identifier
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 8 | | Type = 2 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (32 bits) | | IPv4 Address (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is present if the signaled LSP is to be used as a numbered This TLV is present if the signaled LSP is to be used as a
component link of a bundled TE link. In this case, the identifier numbered component link of a bundled TE link. In this case, the
(numbered or unnumbered) in the main body of the identifier (numbered or unnumbered) in the main body of the
LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of which LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of
this LSP is a component, and the IPv4 Address field of this TLV which this LSP is a component, and the IPv4 Address field of
specifies the numbered identifier that is assigned to this component this TLV specifies the numbered identifier that is assigned to
link within the bundle. this component link within the bundle.
This TLV MUST NOT be present in the same instance of the This TLV MUST NOT be present in the same instance of the
LSP_TUNNEL_INTERFACE_ID object as a TLV with type 1 (unnumbered LSP_TUNNEL_INTERFACE_ID object as a TLV with type 1 (unnumbered
component link identifier). component link identifier).
3.6. LSA advertisement 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
TE links created as described above. The link state may be with 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
signal the path for the LSPs that support the TE links, or another and signal the path for the LSPs that support the TE links, or
IGP instance. In the former case, the address space for the link another IGP instance. In the former case, the address space for
state MUST be the same as that used to establish the LSPs. In the the link state MUST be the same as that used to establish the
latter case, the address space for the link state MAY be different, LSPs. In the latter case, the address space for the link state
which means that addresses already allocated in the IGP instance used MAY be different, which means that addresses already allocated
to establish the LSPs MAY be used by the advertised TE link without in the IGP instance used to establish the LSPs MAY be used by
any ambiguity. the advertised TE link without any ambiguity.
In the IGP the TE Router ID of the ingress LSR is taken from the In the IGP the TE Router ID of the ingress LSR is taken from the
Tunnel Sender Address in the Sender Template object. It is assumed Tunnel Sender Address in the Sender Template object. It is
that the ingress LSR knows the TE Router ID of the egress LSR since assumed that the ingress LSR knows the TE Router ID of the
it has chosen to establish an LSP to that LSR and plans to use the egress LSR since it has chosen to establish an LSP to that LSR
LSP as a TE link. and plans to use the LSP as a TE link.
The link interface addresses or link interface identifiers for the The link interface addresses or link interface identifiers for
forward and reverse direction links are taken from the 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
the LSA is advertised into a IGP instance different from the one used when the LSA is advertised into a IGP instance different from
to establish the LSP because the addresses MAY be allocated in both the one used to establish the LSP because the addresses MAY be
domains. allocated in both domains.
4. 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]
stitching [STITCH]. and LSP stitching [STITCH].
5. 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
used in combination with the new mechanisms described here and is safely used in combination with the new mechanisms described
functionally equivalent to using the new C-Type indicating an here and is functionally equivalent to using the new C-Type
unnumbered link with target IGP instance identifier with the Target indicating an unnumbered link with target IGP instance
IGP Instance value set to 0xffffffff. identifier with the Target 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
issue as an informal survey indicated that dynamically signaled an issue as an informal survey indicated that dynamically
numbered FAs had not been deployed. Indeed it was the attempt to signaled numbered FAs had not been deployed. Indeed it was the
implement numbered FAs that gave rise to the work on this document. attempt to implement numbered FAs that gave rise to the work on
this document.
6. 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
interface identifier that it provides could make an RSVP message extra interface identifier that it provides could make an RSVP
harder to spoof. In that respect, the minor extensions to the message harder to spoof. In that respect, the minor extensions
protocol made in this document do not constitute an additional to the protocol made in this document do not constitute an
security risk, but could also be said to improve security. additional 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
an egress LSR advertise an LSP as a TE link MUST be subject to that an egress LSR advertise an LSP as a TE link MUST be subject
appropriate policy checks at the egress LSR. That is, the egress LSR to appropriate policy checks at the egress LSR. That is, the
MUST NOT automatically accept the word of the ingress unless it is egress LSR MUST NOT automatically accept the word of the ingress
configured with such a policy. unless it is configured with such a policy.
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
Types as tabulated in section 2.2 and described in sections 2.2.2, new C-Types as tabulated in section 2.2 and described in
2.2.3 and 2.2.4. sections 2.2.2, 2.2.3 and 2.2.4.
8. Acknowledgement 8. Acknowledgement
The authors would like to thank John Drake and Yakov Rekhter for The authors would like to thank John Drake and Yakov Rekhter for
their valuable discussions 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.
skipping to change at page 17, line 32 skipping to change at page 20, line 31
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 Rekhter, Y., "Signalling Unnumbered Links [RFC3477]Kompella, K. and Rekhter, Y., "Signalling Unnumbered
in Resource ReSerVation Protocol - Traffic Engineering Links in Resource ReSerVation Protocol - Traffic
(RSVP-TE)", RFC 3477, January 2003. Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC4201] Kompella, K., Rekhter, Y., and Berger, L.," Link Bundling [RFC4201]Kompella, K., Rekhter, Y., and Berger, L.," Link
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 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
(TE) Extensions to OSPF Version 2", RFC 3630, September Engineering (TE) Extensions to OSPF Version 2", RFC
2003. 3630, September 2003.
[RFC4204] Lang, J. (Ed.), "Link Management Protocol (LMP)", RFC [RFC4105]Le Roux, J.-L., Vassuer, J.-P., and Boyle, J. (Eds.),
4204, October 2005. "Requirements for Inter-Area MPLS Traffic Engineering",
RFC 4105, June 2005.
[MLN] Shiomoto, K., et al, " Requirements for GMPLS-based multi- [RFC4204]Lang, J. (Ed.), "Link Management Protocol (LMP)",
region and multi-layer networks (MRN/MLN)", draft-ietf- RFC 4204, October 2005.
ccamp-gmpls-mln-reqs, (work in progress).
[RFC4726]Farrel, A., Vasseur, J.-P., and Ayyangar, A., " A
Framework for Inter-Domain Multiprotocol Label
Switching Traffic Engineering ", RFC 4726, November
2006.
[MLN-REQ]Shiomoto, K., et al, "Requirements for GMPLS-based
multi-region and multi-layer networks (MRN/MLN)",
draft-ietf-ccamp-gmpls-mln-reqs, (work in progress).
[PCE-INTER-LAYER-REQ] Oki, E. (Ed.), " PCC-PCE Communication
and PCE Discovery Requirements for Inter-Layer Traffic
Engineering ", draft-ietf-pce-inter-layer-req, (work in
progress).
Author's Addresses Author's Addresses
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
skipping to change at page 18, line 21 skipping to change at page 22, line 4
Author's Addresses Author's Addresses
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
Google Inc. Google Inc.
Email: rabbat@alum.mit.edu Email: rabbat@alum.mit.edu
Arthi Ayyangar Arthi Ayyangar
Nuova Systems Juniper Networks
2600 San Tomas Expressway 1194 N. Mathilda Ave.
Santa Clara, CA 95051 Sunnyvale, CA 94089
Email: arthi@nuovasystems.com United States of America
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 Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada. 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
Intellectual Property Rights or other rights that might be claimed to any Intellectual Property Rights or other rights that might be
pertain to the implementation or use of the technology described in claimed to pertain to the implementation or use of the
this document or the extent to which any license under such rights technology described in this document or the extent to which any
might or might not be available; nor does it represent that it has license under such rights might or might not be available; nor
made any independent effort to identify any such rights. Information does it represent that it has made any independent effort to
on the procedures with respect to rights in RFC documents can be identify any such rights. Information on the procedures with
found in BCP 78 and BCP 79. 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 Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the
such proprietary rights by implementers or users of this use of 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
http://www.ietf.org/ipr. repository at 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
copyrights, patents or patent applications, or other proprietary any copyrights, patents or patent applications, or other
rights that may cover technology that may be required to implement proprietary rights that may cover technology that may be
this standard. Please address the information to the IETF at required to implement this standard. Please address the
ietf-ipr@ietf.org information to the IETF at ietf-ipr@ietf.org
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the Copyright (C) The IETF Trust (2008). This document is subject
rights, licenses and restrictions contained in BCP 78, and except as to the rights, licenses and restrictions contained in BCP 78,
set forth therein, the authors retain all their rights. 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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 102 change blocks. 
467 lines changed or deleted 612 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/