draft-ietf-ccamp-lsp-hierarchy-bis-03.txt   draft-ietf-ccamp-lsp-hierarchy-bis-04.txt 
Network Working Group K. Shiomoto (Ed.)
Network Working Group K. Shiomoto (NTT) Internet Draft NTT
Internet Draft R. Rabbat (Google) Updates: 3477, 4206 A. Farrel (Ed.)
Updates: 3477, 4206 A. Ayyangar (Juniper Networks) Proposed Category: Proposed Standard Old Dog Consulting
Proposed Category: Proposed Standard A. Farrel (Old Dog Consulting) Created: October 15, 2008
Z. Ali (Cisco Systems, Inc.) Expires: April 15, 2008
Expires: August 2008 February 22, 2008
Procedures for Dynamically Signaled Procedures for Dynamically Signaled
Hierarchical Label Switched Paths Hierarchical Label Switched Paths
draft-ietf-ccamp-lsp-hierarchy-bis-03.txt
draft-ietf-ccamp-lsp-hierarchy-bis-04.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
any applicable patent or other IPR claims of which he or she is applicable patent or other IPR claims of which he or she is aware
aware have been or will be disclosed, and any of which he or she have been or will be disclosed, and any of which he or she becomes
becomes aware will be disclosed, in accordance with Section 6 of aware will be disclosed, in accordance with Section 6 of BCP 79.
BCP 79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet Engineering
Engineering Task Force (IETF), its areas, and its working groups. Task Force (IETF), its areas, and its working groups. Note that
Note that other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet- time. It is inappropriate to use Internet-Drafts as reference
Drafts as reference material or to cite them other than as "work material or to cite them other than as "work in progress."
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 August 22,2008.
Abstract Abstract
This document discusses topics related to hierarchical and Label Switched Paths (LSPs) set up in Multiprotocol Label Switching
stitched Generalized Multiprotocol Label Switching (GMPLS) Label (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links
Switched Paths (LSPs). It describes extensions to allow an for carrying traffic in those networks or in other (client) networks.
egress to identify that a bi-directional LSP will be used as a
dynamically signaled Forwarding Adjacency LSP (FA-LSP) or as a Protocol extensions already exist to facilitate the establishment of
Routing Adjacency (RA). In addition, the document also discusses an LSP as a numbered traffic engineering (TE) link within the same
the issue of how to indicate that an LSP should be advertised as instance of the routing as is used to advertise the links that it
a traffic engineering (TE) link into a different instance of the traverses creating a Forwarding Adjacency (FA). This document extends
IGP, and how to identify the instance that should be used. those mechanisms to support unnumbered FAs.
This document also defines how to indicate that an LSP should be
advertised as a link in another instance of the routing protocol (for
instance in a client network) and which instance to use. Furthermore,
mechanisms are defined to indicate when an LSP is to be used as a
component link of a TE link bundle and to identify the bundle.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described document are to be interpreted as described in [RFC2119].
in [RFC2119].
Table of Contents Table of Contents
1. Introduction and Problem Statement..........................3 1. Introduction and Problem Statement ............................. 1
1.1. LSP Hierarchy............................................3 1.1. Background ...................................................
1.2. LSP advertisement and Usage...............................4 1.1.1. Hierarchical LSPs ..........................................
1.3. Problem Statement........................................6 1.1.2. LSP Stitching Segments .....................................
1.4. Current Approaches and Shortcomings.......................8 1.1.3. Private Links ..............................................
1.5. Contents of This Document.................................9 1.1.4. Routing Adjacencies ........................................
2. Revision history...........................................9 1.1.5. Forwarding Adjacencies .....................................
2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.9 1.1.5. Client/Server Networks .....................................
2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01.9 1.1.6. Link Bundles ...............................................
2.3. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-02.10 1.2. Desired Function .............................................
3. Proposed Solution..........................................10 1.3. Existing Mechanisms ..........................................
3.1. IGP Instance Identification...............................11 1.3.1. LSP Setup ..................................................
3.2. LSP advertisement and Usage Identification................11 1.3.2. Routing Adjacency Establishment and Link State Advertisement
3.3. Bundling.................................................12 1.3.3. TE Link Advertisement ......................................
3.4. LSP_TUNNEL_INTERFACE_ID Object............................12 1.3.4. Configuration and Management Techniques ....................
3.4.1. Unnumbered link.........................................13 1.3.5. Signaled Unnumbered FAs ....................................
3.4.2. IPv4 numbered link......................................14 1.3.6. Establishing Numbered FAs Through Signaling and Routing ....
3.4.3. IPv6 numbered link......................................15 1.4. Overview of Required Extensions ..............................
3.4.4. Unnumbered link with target IGP instance identifier......16 1.4.1. Efficient Signaling of Numbered FAs ........................
3.4.5. Message Formats........................................16 1.4.2. LSPs for Use as Private Links ..............................
3.5. TLVs.....................................................17 1.4.3. Signaling an LSP For use in Another Network ................
3.5.1. Unnumbered Component Link Identifier....................17 1.4.4. Signaling an LSP for Use in a Link Bundle ..................
3.5.2. IPv4 Numbered Component Link Identifier.................18 1.4.5. Support for IPv4 and IPv6 ..................................
3.6. LSA advertisement........................................18 1.4.6. Backward Compatibility .....................................
4. Applicability Statement.....................................19 2. Overview of Solution ...........................................
5. Backward Compatibility Considerations.......................19 2.1. Common Approach for Numbered and Unnumbered Links ............
6. Security Considerations.....................................19 2.2. LSP Usage Indication .........................................
7. IANA Considerations........................................20 2.3. IGP Instance Identification ..................................
8. Acknowledgement............................................20 2.4. Link Bundle Identification ...................................
9. References.................................................20 2.5. Backward Compatibility .......................................
9.1. Normative References.....................................20 3. Mechanisms and Protocol Extensions .............................
9.2. Informative References....................................20 3.1. LSP_TUNNEL_INTERFACE_ID Object ...............................
Author's Addresses............................................21 3.1.1. Existing Definition and Usage ..............................
Intellectual Property Statement................................22 3.1.2. Unnumbered Links with Action Identification ................
Copyright Statement...........................................23 3.1.3. IPv4 Numbered Links with Action Identification .............
3.1.4. IPv6 Numbered Links with Action Identification .............
3.2. Target IGP Identification TLV ................................
3.3. Component Link Identification TLV ............................
3.3.1. Unnumbered Component Link Identification ...................
3.3.2. Numbered Component Link Identification .....................
3.4. Link State Advertisement .....................................
3.5. Message Formats ..............................................
3.6. Error Cases and Non-Acceptance ...............................
3.7. Backward Compatibility .......................................
4. Security Considerations ........................................
5. IANA Considerations ............................................
5.1. New Class Types ..............................................
5.2. Hierarchy Actions ............................................
5.3. New Error Codes and Error Values .............................
6. Acknowledgements ...............................................
7. References .....................................................
7.1. Normative References .........................................
7.2. Informative References .......................................
8. Editors' Addresses .............................................
9. Authors' Addresses .............................................
1. Introduction and Problem Statement 1. Introduction and Problem Statement
1.1. LSP Hierarchy [RFC4206] defines how to set up Label Switched Paths (LSPs) in
Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering
(TE) networks to be used as hierarchical Label Switched Paths
(H-LSPs).
LSP hierarchy has been developed to improve the scalability of [RFC4201] describes how to collect together TE links between the same
Generalized Multi-Protocol Label Switching (GMPLS) by allowing pair of nodes and advertise them as a single TE link called a link
Label Switched Paths (LSPs) to be aggregated into a hierarchy of bundle.
such LSPs [RFC4206]. An LSP may be advertised as a traffic
engineering (TE) 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 (FA), and the LSP is known as an
FA-LSP.
[RFC4206] defines the operation as follows for a numbered FA: [RFC5212] presents a framework and requirements for multilayer
networks (MLNs). This includes the establishment of an LSP in a
server network that is used as a link in a client network.
1. The ingress signals the LSP using a /31 sender address that it As set out later in this document, issues have been identified during
allocates as the source address in the signaling message deployment with how LSPs are established and made available for use
(tunnel sender address in the Sender Template object of the as H-LSPs or as components of a link bundle and advertised
Path message), and targeting the TE router ID of the egress appropriately in an interior gateway protocol (IGP). These issues
(destination address in the Sender object of the Path relate to coordinating between the LSP's end points the use to which
message). the LSP is put.
2. The egress sets up the LSP using normal procedures and This document gives some basic background, describes the
allocating the partner address of the assigned /31 address in requirements, sets out the mechanisms that already exist, and
the local interface address. enumerates the protocols extensions and mechanisms that are needed.
The document goes on to present the necessary additions to the GMPLS
protocols.
3. The ingress then forms a Forwarding Adjacency (FA) out of that 1.1. Background
LSP by advertising it as a Traffic Engineering (TE) link using
the routing protocol (OSPF/ISIS) and using the /31 address to
identify the local end of the TE link.
4. When the egress receives the TE link advertisement, it checks 1.1.1. Hierarchical LSPs
the Link-ID address of the TE advertisement against its own TE
Router ID. If it matches its own TE Router ID, the egress
checks the advertising router ID of the TE advertisement
against the ingress addresses of all LSPs for which it is the
egress and finds the address match with the advertising router
ID of the TE advertisement.
5. The egress then advertises the FA LSP as a TE link setting the [RFC3031] describes how Multiprotocol Label Switching (MPLS) labels
advertising TE Router ID in the Link-ID and the partner may be stacked so that LSPs may be nested with one LSP running
address of the assigned /31 address in the local interface through another. This concept of H-LSPs is formalized in [RFC4206]
address. with a set of protocol mechanisms for the establishment of an H-LSP
that can carry one or more other LSPs.
Nesting of LSPs originated by other LSRs into that LSP can be [RFC4206] goes on to explain that an H-LSP may carry other LSPs only
achieved by using the label stack construct. according to their switching types. This is a function of the way
labels are carried. In a packet switch capable (PSC) network, the
H-LSP can carry other PSC LSPs using the MPLS label stack. In non-
packet networks where the label is implicit, label stacks are not
possible and rely on the ability to nest switching technologies.
Thus, for example, a lambda switch capable (LSC) LSP can carry a time
division multiplexing (TDM) LSP, but cannot carry another LSC LSP.
1.2. LSP advertisement and Usage Signaling mechanisms defined in [RFC4206] allow an H-LSP to be
treated as a single hop in the path of another LSP (i.e., one hop of
the LSP carried by the H-LSP). This mechanism is known as "non-
adjacent signaling."
There are three different ways in which traffic can be forwarded 1.1.2. LSP Stitching Segments
to
There are different ways in which an LSP can be used to carry LSP stitching is defined in [RFC5150]. It enables LSPs of the same
traffic and potentially advertised as a link by a routing switching type to be included (stitched) as hops in an end-to-end
protocol. LSP. The stitching LSP (S-LSP) is used in the control plane in the
same way as an H-LSP, but in the data plane the LSPs are stitched so
that there is no label stacking or nesting of technologies. Thus, an
S-LSP must be of the same switching technology as the end-to-end LSP
that it facilitates.
First, the LSP can be used either as a link inside or outside 1.1.3. Private Links
the network that was used to form the LSP. In the former case,
the LSP can carry traffic that could have been routed down the
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.
Second, the link formed by the LSP can be advertised by the An H-LSP or S-LSP can be used as a private link. Such links are known
routing protocol as available to carry traffic, or can be kept by their end-points, but are not more widely known. They can be used
as a private link known only to the head and tail end LSRs. to carry traffic between the end-points, but are not usually used to
carry traffic that is going beyond the egress of the LSP.
These two options give rise to four possible combinations as 1.1.4. Routing Adjacencies
follows.
1. The LSP is created and advertised as a TE link in the same A routing adjacency is formed between two IGP-speakers that are
instance of the routing protocol as was used to advertise the logically adjacent. In this sense, 'logically adjacent' means that
links that it traverses. This is a Forwarding Adjacency as the routers have a protocol tunnel between them through which they
described in [RFC4206]. Note that no routing adjacency is formed can exchange routing protocol messages. The tunnel is also usually
over the LSP. available for carrying IP data although a distinction should be made
in GMPLS networks between data plane traffic and control plane
traffic.
2. The LSP is created and made available to carry traffic in the Routing adjacencies for forwarding data traffic are only relevant in
same network as the links that it traverses, but it is not PSC networks (i.e., IP/MPLS networks).
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 1.1.5. Forwarding Adjacencies
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 A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link
being advertised in the client network routing protocol. Just as created from an LSP and advertised in the same instance of the
in case 2, the existence of the LSP as a protocol tunnel is control plane that advertises the TE links from which the LSP is
known only to the tunnel LSP points which are nodes in the constructed. The LSP itself is called an FA-LSP.
client network.
Notes: Thus, an H-LSP or S-LSP may form an FA such that it is advertised as
a TE link in the same instance of the routing protocol as was used to
advertise the TE links that the LSP traverses.
a. Case 1 includes the multi-layer traffic engineering scenario As observed in [RFC4206] the nodes at the ends of an FA would not
where a single instance of the routing protocol is used across usually have a routing adjacency.
both layers. This situation was particularly envisaged in
[RFC4206].
b. The example cited in case 2 is special because the 1.1.5. Client/Server Networks
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 An LSP may be created in one network and used as a link (sometimes
explained in Note a. called a virtual link) in another networks [RFC5212]. In this case
the networks are often referred to as server and client networks
respectively.
d. The client network in case 3 may be a different technology TE The server network LSP is used as an H-LSP or an S-LSP as described
network (such as a GMPLS TDM network that operates over a GMPLS above, but does not form an FA because the client and server networks
WDM network, or an MPLS-TE network operating over a GMPLS run separate instances of the control plane routing protocols.
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 The virtual link may be used in the client network as a private link
within different IGP areas [RFC4105]. or may be advertised in the client network IGP. Additionally, the
link may be used in the client network to form a routing adjacency
and/or as a TE link.
f. IGP shortcuts should be treated with extreme caution when 1.1.6. Link Bundles
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 [RFC4201] recognizes that a pair of adjacent routers may have a large
hierarchical LSP as an IGP shortcut within the control plane. number of TE links that run between them. This can be a considerable
burden to the operator who may need to configure them, and to the IGP
that must distribute information about each of them. A TE link bundle
is defined by [RFC4201] as a TE link that is advertised as an
aggregate of multiple TE links that could have been advertised in
their own right. All TE links that are collected into a TE link
bundle have the same TE properties.
1.3. Problem Statement Thus, a link bundle is a shorthand that improves the scaling
properties of the network.
The extensions described in this document are intended for Since a TE link may, itself, be an LSP (either an FA or a virtual
dynamically signaled bi-directional Forwarding Adjacency LSPs link), a link bundle may be constructed from FA-LSPs or virtual
(FA-LSPs). In particular this document addresses the following links.
points:
(1) How to let the egress node know that this bi-directional 1.2. Desired Function
LSP needs to be advertised as an FA, or as an RA, or as an
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 It should be possible to signal an LSP and automatically coordinate
a TE link bundle and advertised as part of that bundle. its use and advertisement in any of the ways described in Section 1.3
with minimum involvement from an operator. The mechanisms used should
be applicable to numbered and unnumbered links, and should not
require implementation complexities.
(3) How to identify the routing instance in which such an 1.3. Existing Mechanisms
advertisement should happen.
We should note that these aspects are equally applicable to both This section briefly introduces existing protocol mechanisms used to
numbered and unnumbered TE links. satisfy the desired function described in Section 1.2.
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.
When the mechanism set out in section 1.1 is used for numbered 1.3.1. LSP Setup
FAs, there is no way to carry the TE Router ID of the ingress
LSR in the RSVP signaling message (Path message) and there is no
way to indicate 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 Both unidirectional LSPs and bidirectional LSPs are signaled from the
information in the signaling protocol during the establishment ingress label switching router (LSR) to the egress LSR. That is, the
of LSPs that will be advertised as unnumbered TE links. If the ingress LSR is the initiator, and the egress learns about the LSP
LSP_TUNNEL_INTERFACE_ID object is present, it indicates that the through the signaling protocol [RFC3209], [RFC3473].
LSP is to be advertised as a TE link, and it contains the TE
Router ID of the ingress LSR. This mechanism resolves many of
the issues listed above, and provides a solution for unnumbered
TE links, however, the LSP_TUNNEL_INTERFACE_ID object cannot be
used for numbered FAs as currently defined, and so the problem
remains for numbered TE links.
Related to the above problem, a few key observations are worth 1.3.2. Routing Adjacency Establishment and Link State Advertisement
noting:
6. The term FA is applicable only when an LSP is created and used Although hosts can discover routers (for example through ICMP
as a TE link in the same instance of the IGP. [RFC4206] did [RFC1256]), routing adjacencies are usually configured at both ends
not consider scenarios where an LSP is created (and of the adjacency. This requires that each router know the identity
maintained) by one instance of the IGP, and is used as a (TE) of the router at the other end of the link connecting the routers,
link by another instance of IGP. This leaves open the question and know that the IGP is to be run on this link.
of advertising a TE link into a different instance of the IGP
as is needed in multi-region/multi-layer networks [MLN-REQ],
and how to identify which instance of the IGP should be used.
In addition, the TE link advertised into the different IGP
instance may be associated with an IGP neighbor adjacency. We
call it a routing adjacency (RA). The decision as to whether
the link should be advertised to MPLS TE topology or IP
topology or both depends on operator policy. Therefore, a
mechanism to indicate the choice to the Egress node is needed.
7. [RFC4206] provides a way to exchange numbered identifiers for Once a routing adjacency has been established, a pair of routers may
the TE link, but this does not clearly state that the Ingress use the IGP to share information about the links available for
node can use presence of the LSP_TUNNEL_INTERFACE_ID object as carrying IP traffic in the network.
a trigger for TE link advertisement at the egress node.
8. It is important to note that an LSP that is set up in a server Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version
GMPLS transport network and advertised as a TE link in a 3 [RFC5340], and IS-IS [RFC1195].
client MPLS data network is NOT an FA-LSP according to the
definitions explained in point 1, above. This is the case
regardless of whether the GMPLS network is packet- or non-
packet-capable.
9. When an egress checks the address of the advertised TE link to 1.3.3. TE Link Advertisement
find the LSP sender (Recall step (4) as described in section
1.1), it must check the Link-ID address of all received TE
advertisements against its own TE Router ID. If it matches
its own TE Router ID, the egress checks the advertising router
ID of the TE advertisement against the ingress addresses of
all LSPs for which it is the egress. It is an assertion of
the authors that this method is not scalable due to the amount
of processing needed for all the TE Link State Advertisements
(LSAs).
10.Further, if a set of LSPs are to be bundled into a single TE Extensions have been made to IGPs to advertise TE link properties
link [RFC4201] then not only is it necessary to identify to the ([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]) and
egress that the LSP will be advertised as part of a TE link, it also to advertise link properties in GMPLS networks ([RFC4202],
is also necessary to indicate the identity of the TE link. This [RFC4203], and [RFC5307]).
identity is distinct from the identity of the component link.
Thus, in this case an additional identifier needs to be signaled,
but none is currently available.
1.4. Current Approaches and Shortcomings TE link advertisement can be performed by the same instance of the
IGP as is used for normal link state advertisement, or can use a
separate instance. Furthermore, the ends of a TE link advertised in
an IGP do not need to form a routing adjacency. This is particularly
the case with FAs as described in Section 1.1.5.
[RFC3477] provides a mechanism to exchange unnumbered 1.3.4. Configuration and Management Techniques
identifiers for the TE link during FA-LSP establishment, and
this can be used as a notification to the egress that the LSP
will be used as a TE link. So, for unnumbered TE links, there is
a well-defined indication available, and this could be
documented and used as a trigger for TE link advertisement by
the egress.
The use of unnumbered TE links may be arguably more sensible LSPs are usually created as the result of a management action. This
than assigning numbers to FAs, especially in the case of large is true even when a control plane is used ? the management action is
networks. Some operators though prefer to consistently use a request to the control plane to signal the LSP.
numbered TE links for both static and dynamic (that is, FA) TE
links in their networks. In the case of numbered TE links,
however, there is no available indication to allow the egress to
know that an LSP should be advertised as a TE link.
In addition, using unnumbered TE links does not address the If the LSP is to be used as an H-LSP or S-LSP, management commands
issue of advertising TE links into a different instance of the can be used to install the LSP as a link. The link must be defined,
IGP. There is no defined mechanism to identify whether it should interface identifiers allocated, and the end points configured to
be advertised as an FA, a full Routing Adjacency (RA), or it know about (and advertise, if necessary) the new link.
should be used as a local virtual link.
The Link Management Protocol (LMP) [RFC4204] could possibly be If the LSP is to be used as part of a link bundle, the operator must
run on remote adjacencies between the endpoints of an LSP. But decide which bundle it forms part of and ensure that that information
LMP peer discovery would be required for dynamic LMP peering and is configured at the ingress and egress, along with the necessary
is not currently specified. In addition, the concept of a interface identifiers.
remote LMP adjacency remains unproven. Lastly, there would be a
requirement that all layers/regions in a MLN network run LMP.
This may not be the case in existing networks and would put
undue burden on the network operator to deploy another protocol.
1.5. Contents of This Document These mechanisms are perfectly functional and quite common in MLNs,
but require configuration coordination and additional management.
They are open to user error and misconfiguration that might result in
the LSP not being used (a waste of resources) or the LSP being made
available in the wrong way with some impact on traffic engineering.
This document provides a consolidated way of exchanging TE link 1.3.5. Signaled Unnumbered FAs
identifiers when an LSP is established through signaling. It
also 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 the egress. The proposed mechanism applies
equally to Hierarchical LSPs (H-LSPs) and Stitchable LSPs (S-
LSPs).
The method described below extends the method described in [RFC3477] describes how to establish an LSP and to make it available
[RFC3477], which is applied for an FA-LSP represented as an automatically as a TE link in the same instance of the routing
unnumbered TE link. protocol as advertises the TE links it traverses, using IPv4-based
unnumbered identifiers to identify the new TE link. That is,
[RFC3477] describes how to create an unnumbered FA.
2. Revision history The mechanism, as defined in Section 3 of [RFC3477], is briefly as
follows:
2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00 - The ingress of the LSP signals the LSP as normal using a Path
message, and includes an LSP_TUNNEL_INTERFACE_ID object. The
LSP_TUNNEL_INTERFACE_ID object identifies:
- The sender's LSR Router ID
- The sender's interface ID for the TE link being created
o Fixed page formatting - The egress of the LSP responds as normal to accept the LSP and set
it up, and includes an LSP_TUNNEL_INTERFACE_ID object. The
LSP_TUNNEL_INTERFACE_ID object identifies:
- The egress's LSR Router ID
- The egress's interface ID for the TE link being created.
o Updated author addresses - Following the exchange of the Path and Resv messages, both the
ingress and the egress know that the LSP is to be advertised as a
TE link in the same instance of the routing protocol as was used to
advertise the TE links that it traverses, and also know the
unnumbered interface identifiers to use in the advertisement.
o Readability fixes [RFC3477] does not include mechanisms to support IPv6-based
unnumbered identifiers, nor IPv4 or IPv6 numbered identifiers.
2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01 1.3.6. Establishing Numbered FAs Through Signaling and Routing
o Added indication of bundled link [RFC4206] describes procedures to establish an LSP and to make it
available automatically as a TE link that is identified using IPv4
addresses in the same instance of the routing protocol as advertised
the TE links it traverses (that is, as a numbered FA).
o Added "ACTION" field, which obsoletes R and F bits The mechanism, as defined in [RFC4206], is briefly as follows:
o Readability fixes - The ingress of the LSP signals the LSP as normal using a Path
2.3. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-02 message, and sets the IPv4 tunnel sender address to the IP address
it will use to identify its interface for the TE link being
created. This is one address from a /31 pair.
o Rewrite Section 1.2 - The egress of the LSP responds as normal to accept the LSP and set
o Updated author addresses it up. It infers the address that it must assign to identify its
o Readability fixes interface for the TE link being created as the partner address of
the /31 pair.
3. Proposed Solution - The ingress decides whether the LSP is to be advertised as a TE
link (i.e., as an FA). If so, it advertises the link in the IGP
in the usual way.
The following method allows the ingress and egress LSRs to - If the link is unidirectional, nothing more needs to be done. If
exchange the link addresses or link identifiers (including the the link is bidirectional, the egress must also advertise the link,
node ID) of the ends of a numbered or unnumbered TE link to be but it does not know that advertisement is required as there is no
formed from an LSP. It is an extension of the procedures indication in the signaling messages.
defined in [RFC3477] for unnumbered TE links.
If an ingress LSR that originates an LSP, intends to advertise - When the ingress's advertisement of the link is received by the
this LSP as a TE link in IS-IS or OSPF [RFC4206], the ingress egress it must check to see whether it is the egress of the LSP
LSR MUST allocate an address or identifier to the TE link (just that formed the link. Typically this means:
like for any other TE link), and it MUST do this before the LSP - Check to see if the link advertisement is new
setup request is signaled. Moreover, the Path message used for - Check to see if the Link-ID address in the received advertisement
establishing the LSP that will be used to form the TE link MUST matches its own TE Router ID
contain the LSP_TUNNEL_INTERFACE_ID object (as extended and - Checks the advertising router ID from the advertisement against
described below), with the interface address or identifier the ingress address of each LSPs for which it is the egress
allocated by the ingress LSR. - Deduce the LSP that has been advertised as a TE link and issue
the corresponding advertisement for the reverse direction.
If the Path message for the H-LSP/S-LSP contains the It is possible that some reduction in processing can be achieved by
LSP_TUNNEL_INTERFACE_ID object, then the egress LSR (assuming it mapping based on the /31 pairing, but nevertheless, there is a fair
accepts the LSP request) MUST allocate an address or identifier amount of processing required, and this does not scale well in large
to the TE link that will be formed (just like for any other networks.
numbered or unnumbered TE link). Furthermore, the Resv message
for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with
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 No explanation is provided in [RFC4206] of how to create numbered
Tunnel Sender Address in the Sender Template Object of the Path IPv6 FAs.
message MUST be set to the TE Router ID of the ingress LSR. We
should note that this is a change from the method described in
[RFC4206].
Once the egress LSR has successfully sent a Resv message as Note that this document deprecates this procedure as explained in
described above it SHOULD advertise the LSP as a TE link using Section 1.4.6.
the addresses/identifiers exchanged. Once the Resv has been
processed by the ingress LSR and the LSP has been successfully
established, the ingress LSR SHOULD advertise the LSP as a TE
link using the addresses/identifiers exchanged.
Once the TE link advertisement has been flooded it is available 1.4. Overview of Required Extensions
for use in path computation and LSP signaling just like any
other TE link.
3.1. IGP Instance Identification This section provides a brief outline of the required protocol
extensions.
The mechanism described so far allows an ingress LSR to indicate 1.4.1. Efficient Signaling of Numbered FAs
that 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 LSP setup.
However, it is also necessary to indicate into which instance of The mechanism described in Section 1.3.6. is inefficient. The egress
the IGP the advertisement should be made. This is only must wait until it receives an advertisement from the ingress before
necessary if the LSP is to be advertised as a TE link into a it knows that the LSP is to be installed as a TE link and advertised
different instance of the IGP, and the default behavior may as an FA. Further, it must parse all received advertisements to
safely be left with the LSP advertised into the same instance of determine if any is the trigger for it to advertise an FA.
the IGP.
Indication of the IGP in which the advertisement is to be made An efficient signaling mechanism is required so that the egress is
first requires that a 32-bit identifier be assigned to each of informed by the ingress during LSP establishment.
the IGP instances within a network, and that ingress and egress
LSRs have the same understanding of these numbers. This is a
management configuration exercise outside the scope of this
document.
Once these numbers have been assigned, they MAY be signaled as 1.4.2. LSPs for Use as Private Links
additional information in the LSP_TUNNEL_INTERFACE_ID object to
indicate to which instance of the IGP the object applies.
The IGP instance identifier value of 0xffffffff is reserved to There is currently no mechanism by which an ingress can indicate that
indicate that the TE link SHOULD be advertised into the same an LSP is set up for use as a private link. Any attempt to make it
instance of the IGP as was used to establish the LSP. Similarly, a link would currently cause it to be advertised as an FA.
absence of the IGP instance identifier means that an FA is to be
established (in the same IGP instance).
3.2. LSP advertisement and Usage Identification A signaling mechanism is needed to identify the use to which an LSP
is to be put.
As mentioned earlier, the egress node also needs to know if it 1.4.3. Signaling an LSP For use in Another Network
needs to create a full routing adjacency or forwarding adjacency
or just need to treat the LSP as a local virtual link. The
extensions defined in the following also specify the LSP
advertisement and usage treatment.
It is not mutually exclusive whether the LSP has routing The existing signaling/routing mechanisms are designed for use in the
adjacency and whether it has forwarding adjacency. The LSP can creation of FAs. That is, the TE link created is advertised in the
have both routing and forwarding adjacency. In this case, the LSP single IGP instance.
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 The numbered TE link mechanism (Section 1.3.6) could, in theory, be
used in an MLN with multiple IGP instances if the addressing model is
kept consistent across the networks, and if the egress searches all
advertisements in all IGP instances. But this is complex and does not
work for unnumbered interfaces.
It is possible to treat LSPs as component links and to bundle A signaling mechanism is required to indicate in which IGP instance
them into a single TE link. However there is currently no way to the TE link should be advertised.
signal that an LSP will be used as part of a bundle and to
identify the bundled link to which the LSP is supposed to belong.
Each LSP that is to form a component link is signaled using the 1.4.4. Signaling an LSP for Use in a Link Bundle
LSP_TUNNEL_INTERFACE_ID object to identify the TE link bundle to
which the LSP will belong. Thus multiple LSPs may be signaled
with the same address/identifier in the LSP_TUNNEL_INTERFACE_ID
object. When the LSP is to form a component link, the
LSP_TUNNEL_INTERFACE_ID object MUST also contain an additional
TLV to identify the component link. This may be a numbered or
unnumbered identifier.
Multiple LSPs may be signaled with the same address/identifier A signaling mechanism is required to indicate that an LSP is intended
in the LSP_TUNNEL_INTERFACE_ID object. to form a component link of a link bundle, and to identify the
bundle and the IGP instance in which the bundle is advertised.
3.4. LSP_TUNNEL_INTERFACE_ID Object 1.4.5. Support for IPv4 and IPv6
The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a The protocol mechanisms must support IPv4 and IPv6 numbered and
class number of 193, which designates that a node that does not unnumbered TE links.
understand the object SHOULD ignore the object but forward it,
unexamined and unmodified, in all messages resulting from this
message.
[RFC3477] defines one class type to indicate an unnumbered 1.4.6. Backward Compatibility
interface identifier. This document defines three new class
types as follows.
C-Type Meaning The existing protocol mechanisms for unnumbered FAs as defined in
Reference [RFC4206] and [RFC3477] must continue to be supported, and new
---------------------------------------------------------------- mechanisms must be devised such that their introduction will not
1 Unnumbered interface identifier [RFC3477] break existing implementations or deployments.
2 (TBD by IANA) IPv4 interface identifier with target 2.2.2
3 (TBD by IANA) IPv6 interface identifier with target 2.2.3
4 (TBD by IANA) Unnumbered interface with target 2.2.4
Multiple instances of the LSP_TUNNEL_INTERFACE_ID object with C- Note that an informal survey in the CCAMP working group established
Type values 2, 3 or 4 MAY appear in any one Path or Resv message, that there are no significant deployments of numbered FAs established
in which case, each MUST have a different value for the Target using the technique described in [RFC4206] and set out in Section
IGP Instance field. A Path or Resv message MUST NOT contain 1.3.6. Therefore, this document deprecates this procedure.
more than one 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 other C-Type value MUST NOT have Target
IGP Instance set to 0xffffffff.
3.4.1. Unnumbered link 2. Overview of Solution
The unnumbered link identifier defined by [RFC3477] is not This section provides an overview of the mechanisms and protocol
changed by this document. Its usage also remains the same. extensions defined in this document. Details are presented in Section
That is, when present in a Path message it indicates that the 3.
LSP being established SHOULD be advertised by the egress LSR as
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 2.1. Common Approach for Numbered and Unnumbered Links
target IGP instance identifier it cannot identify a specific
instance of the IGP into which this TE link should be advertised.
Similarly, LSP advertisement and usage treatment also needs to
be specified. Thus, 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 use of C-Type 1 is unchanged from
[RFC3477] and is used to create an unnumbered Forwarding
Adjacency.
This object can appear in either a Path message or a Resv The LSP_TUNNEL_INTERFACE_ID object [RFC3477] is extended for use for
message. In the former case, we call it the "Forward Interface all H-LSPs and S-LSPs whether they form numbered or unnumbered, IPv4
ID" for that LSP; in the latter case, we call it the "Reverse or IPv6 links. Different class-types of the object identify the
Interface ID" for the LSP. address type for which it applies.
A Path or Resv message MUST have only one instance of this 2.2. LSP Usage Indication
object with C-Type 1.
3.4.2. IPv4 numbered link The LSP_TUNNEL_INTERFACE_ID object is given flags in a new Actions
field to say how the LSP is to be used. The following categories are
supported:
- LSP is used as an advertised TE link
- LSP is used to form a routing adjacency
- LSP is used to form an advertised TE link and a routing adjacency
- LSP forms a private link and is not advertised
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is 2.3. IGP Instance Identification
defined to carry an IPv4 numbered interface address and to
indicate into which instance of the IGP the consequent TE link An optional TLV is added to the LSP_TUNNEL_INTERFACE_ID object to
should be advertised. identify the IGP instance into which the link formed by the LSP is to
be advertised. If the TLV is absent and the link is to be advertised
as indicated by the Actions field, the link is advertised in the same
instance of the IGP as was used to advertise the TE links it
traverses.
2.4. Link Bundle Identification
When an LSP is to be used as a component link of a link bundle, the
LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how
the bundle is addressed and used, and a new TLV indicates the
component link identifier for the link that the LSP creates.
2.5. Backward Compatibility
Backward compatibility has three aspects.
- Existing mechanisms for unnumbered FAs described in [RFC3477] and
[RFC4206] must continue to work, so that ingress nodes do not have
to be updated when egresses are updated.
- Existing mechanisms for establishing numbered FAs described in
[RFC4206] are safely deprecated by this document as they are not
significantly deployed.
- New mechanisms must be gracefully rejected by existing egress
implementations so that egress nodes do not have to be updated when
ingresses are updated.
3. Mechanisms and Protocol Extensions
This section defines protocol mechanisms and extensions to achieve
the function described in the previous section.
3.1. LSP_TUNNEL_INTERFACE_ID Object
The principal signaling protocol element used to achieve all of the
required functions is the LSP_TUNNEL_INTERFACE_ID object defined in
[RFC3477]. The existing definition and usage continues to be
supported as described in the next section. Subsequent sections
describe new variants of the object (denoted by new Class Types), and
additional information carried in the object by means of extensions.
3.1.1. Existing Definition and Usage
This document does not deprecate the mechanisms defined in [RFC3477]
and [RFC4206]. Those procedures must continue to operate as described
in Section 3.7.
That means that the LSP_TUNNEL_INTERFACE_ID object with Class Type 1
remains unchanged, and can be used to establish an LSP that will be
advertised as an unnumbered TE link in the same instance of the IGP
as was used to advertise the TE links that the LSP traverses. That
is, as an FA. The procedure is unchanged and operates as summarized
in Section 1.3.5.
[RFC3477] does not make any suggestions about where in Path or Resv
messages the LSP_TUNNEL_INTERFACE_ID object should be placed. See
Section 3.5 for recommended placement of this object in new
implementations.
3.1.2. Unnumbered Links with Action Identification
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined
to carry an unnumbered interface identifier and to indicate into
which instance of the IGP the consequent TE link should be
advertised. This does not deprecate the use of C-Type 1.
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 = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Interface Address (32 bits) | | LSR's Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IGP Instance (32 bits) | | Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACTION | PADDING | | Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs | ~ TLVs ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACTION: This field specifies how the LSP advertisement and usage LSR's Router ID
treatment. It indicates if the egress LSR needs to create a full
routing adjacency or forwarding adjacency or just need to treat
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 Unchanged from the definition in [RFC3477].
topology. We should note that it assures the backward
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. Interface ID
"0010": LSP is an RA and FA and is advertised in both IP and
MPLS-TE topologies.
"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 MPLS topology.
The Padding MUST be set to zero on transmission, SHOULD be
ignored and forwarded unchanged, and SHOULD be ignored on
receipt.
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 that LSP; in the latter case, we call it the
"Reverse Interface Address" for the LSP.
3.4.3. IPv6 numbered link Unchanged from the definition in [RFC3477].
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is Actions
defined to carry an IPv6 numbered interface address and to
indicate into which instance of the IGP the consequent TE link This field specifies how the LSP that is being set up is to be
should be advertised. treated.
The field has meaning only on a Path message. On a Resv message
the field SHOULD be set to reflect the value received on the
corresponding Path message, and MUST be ignored on receipt.
The field is composed of bit flags as follows:
-+-+-+-+-+-+-+-
| | | |H|B|R|T|P|
-+-+-+-+-+-+-+-
P-flag (Private)
0 means that the LSP is to be advertised as a link according
to the settings of the other flags.
1 means the LSP is to form a private link and is not to be
advertised in the IGP, but is to be used according to the
settings of the other flags.
T-flag (TE link)
0 means that the LSP is to be used as a TE link.
1 means that the LSP is not to be used as a TE link. It may
still be used as an IP link providing a routing adjacency as
defined by the R-flag.
R-flag (routing adjacency)
0 means that the link is not to be used as a routing
adjacency.
1 means that the link is to be used to form a routing
adjacency.
B-flag (bundle)
0 means that the LSP will not form part of a link bundle.
1 means that the LSP will form part of a bundle. See Section
3.3 for more details.
H-flag (hierarchy/stitching)
The use of an LSP as an H-LSP or as an S-LSP is usually
implicit from the network technologies of the networks and the
LSP, but this is not always the case (for example, in PSC
networks).
0 means LSP to be used as a hierarchical LSP.
1 means LSP to be used as a stitching segment.
Other bits are reserved for future use. They MUST be set to zero
on transmission and SHOULD be ignored on receipt.
Note that all defined bit flags have meaning at the same time.
An LSP that is to form an FA would carry the Actions field set
to 0x00. That is:
P=0 (advertised)
T=0 (TE link)
R=0 (not a routing adjacency)
B=0 (not a bundle)
H=0 (hierarchical LSP)
Reserved
The Reserved bits MUST be set to zero on transmission and SHOULD
be ignored on receipt.
TLVs
Zero, one, or more TLVs may be present. Each TLV is encoded as
follows:
Type (16 bits)
The identifier of the TLV. Two type values are defined in
this document:
1 IGP Instance Identifier TLV
2 Component Link Identifier TLV
Length (16 bits)
Indicates the total length of the TLV in octets. I.e.,
4 + the length of the value field in octets. A value field
whose length is not a multiple of four MUST be zero-padded
so that the TLV is four-octet aligned.
Value
The data for the TLV padded as described above.
If this object is carried in a Path message it is known as the
"Forward Interface ID" for the LSP that is being set up. On a Resv
message the object is known as the "Reverse Interface ID" for the
LSP.
3.1.3. IPv4 Numbered Links with Action Identification
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined
to carry an IPv4 numbered interface address.
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 = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) | | IPv4 Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IGP Instance (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACTION | PADDING | | Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs | ~ TLVs ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Interface Address
This object can optionally appear in either a Path message or a The address assigned to the interface the sender applies to
Resv message. In the former case, we call it the "Forward this 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 Actions
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is See Section 3.1.2.
defined to carry an unnumbered interface identifier and to
indicate into which instance of the IGP the consequent TE link Reserved
should be advertised. This does not deprecate the use of C-Type
1, but extends its utility. See Section 3.1.2.
TLVs
See Section 3.1.2.
If this object is carried in a Path message it is known as the
"Forward Interface ID" for the LSP that is being set up. On a Resv
message the object is known as the "Reverse Interface ID" for the
LSP.
3.1.4. IPv6 Numbered Links with Action Identification
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined
to carry an IPv6 numbered interface address.
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 = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR's Router ID | | IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) | | IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IGP Instance (32 bits) | | IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACTION | PADDING | | IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs | | Actions | Reserved |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Interface Address
This object can optionally appear in either a Path message or a The address assigned to the interface the sender applies to
Resv message. In the former case, we call it the "Forward this LSP.
Interface ID" for that LSP; in the latter case, we call it the
"Reverse Interface ID" for the LSP.
3.4.5. Message Formats Actions
[RFC3477] does not state where in the Path message or Resv See Section 3.1.2.
message the LSP_TUNNEL_INTERFACE_ID object should be placed.
Since [RFC3209] states that all implementations are to handle
all objects received in 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 immediately after the
SENDER_TSPEC object, and in the Resv message immediately after
the FILTER_SPEC object.
3.5. TLVs Reserved
All TLVs of the LSP_TUNNEL_INTERFACE_ID object have the See Section 3.1.2.
following format.
TLVs
See Section 3.1.2.
If this object is carried in a Path message it is known as the
"Forward Interface ID" for the LSP that is being set up. On a Resv
message the object is known as the "Reverse Interface ID" for the
LSP.
3.2. Target IGP Identification TLV
If the LSP being set up is to be advertised as a link, the egress
needs to know which instance of the IGP it should use to make the
advertisement. The default in [RFC4206] and [RFC3477] is that the LSP
is advertised as an FA, that is, in the same instance of the IGP as
was used to advertise the TE links that the LSP traverses.
In order to facilitate an indication from the ingress to the egress
of which IGP instance to use, the IGP Identification TLV is defined
for inclusion in the new variants of the LSP_TUNNEL_INTERFACE_ID
object defined in this document.
The TLV has meaning only in a Path message. It SHOULD NOT be included
in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and MUST be
ignored if found.
If the P-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID
object in a Path message is clear (i.e., zero), this TLV indicates
the IGP instance to use for the advertisement. If the TLV is absent,
the same instance of the IGP should be used as is used to advertise
the TE links that the LSP traverses. Thus, for an FA, the TLV can be
omitted; alternatively, the IGP Instance TLV may be present
identifying the IGP instance or carrying the reserved value
0xffffffff.
If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID
object in a Resv message is set (i.e., one) indicating that the LSP
is not to be advertised as a link, this TLV SHOULD NOT be present and
MUST be ignored if encountered.
The TLV is formatted as described in Section 3.1.2. The Type field
has the value 1, and the Value field has the following content:
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) | | IGP Instance Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length field contains the total length of the TLV including IGP Instance Identifier
the Type and Length fields in bytes A value field whose length
is not a multiple of four MUST be zero-padded so that the TLV is
four-byte aligned.
This document defines two Type values to be used to specify the A 32-bit identifier be assigned to each of the IGP instances
component link identifier that the sending LSR has assigned to within a network, such that ingress and egress LSRs have the same
the LSP if it forms part of a TE link bundle. The consequent understanding of these numbers. This is a management
TLV formats are shown in the next sections. configuration exercise outside the scope of this document.
3.5.1. Unnumbered Component Link Identifier Note that the IGP Instance Identifier might be mapped from an
instance identifier used in the IGP itself (such as section 2.4
of [RFC5340] for OSPFv3, or [OSPFv2-MI] for OSPFv2) as a matter
of network policy. See [OSPF-TI] for further discussion of this
topic in OSPF, and [ISIS-GENAP] for IS-IS.
The value 0xffffffff is reserved to mean that the LSP is to be
advertised in the same instance of the IGP as was used to
advertise the TE links that the LSP traverses.
3.3. Component Link Identification TLV
If the LSP that is being set up is to be used as a component link in
a link bundle [RFC4201], it is necessary to indicate both the
identity of the component link and the identity of the link bundle.
Furthermore, it is necessary to indicate how the link bundle (that
may be automatically created by the establishment of this LSP) is
to be used and advertised.
If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID
object is set, the other fields of the object apply to the link
bundle itself. That is, the interface identifiers (numbered or
unnumbered) and the other flags in the Actions field apply to the
link bundle and not to the component link that the LSP will form.
Furthermore, the IGP Instance Identifier TLV (if present) also
applies to the link bundle and not to the component link.
In order to exchange the identity of the component link, the
Component Link Identifier TLVs are introduced as set out in the
next sections. If the B-flag is set in the Actions field of the
LSP_TUNNEL_INTERFACE_ID object in the Path message, exactly one of
these TLVs MUST be present in the LSP_TUNNEL_INTERFACE_ID object in
both the Path and Resv objects.
3.3.1. Unnumbered Component Link Identification
If the component link is to be unnumbered, the Unnumbered Component
Link Identifier TLV is used. The TLV is formatted as described in
Section 3.1.2. The Type field has the value 2, and the Value field
has the following content:
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 | | Component Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component Link Identifier (32 bits) |
Component Link Identifier
Unnumbered identifier that is assigned to this component link
within the bundle [RFC4201].
3.3.2. IPv4 Numbered Component Link Identification
If the component link is identified with an IPv4 address, the IPv4
Numbered Component Link Identifier TLV is used. The TLV is formatted
as described in Section 3.1.2. The Type field has the value 3, and
the Value field has the following content:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is present if the signaled LSP is to be used as an IPv4 Address
unnumbered component link of a bundled TE link. In this case,
the identifier (numbered or unnumbered) in the main body of the
LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of
which this LSP is a component, and the Component Link Identifier
of this TLV specifies the unnumbered identifier that is assigned
to this component link within the bundle.
This TLV MUST NOT be present in the same instance of the The IPv4 address that is assigned to this component link within
LSP_TUNNEL_INTERFACE_ID object as a TLV with type 2 (numbered the bundle.
component link identifier).
3.5.2. IPv4 Numbered Component Link Identifier 3.3.2. IPv6 Numbered Component Link Identification
If the component link is identified with an IPv6 address, the IPv6
Numbered Component Link Identifier TLV is used. The TLV is formatted
as described in Section 3.1.2. The Type field has the value 4, and
the Value field has the following content:
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 | | IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (32 bits) | | IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is present if the signaled LSP is to be used as a IPv6 Address
numbered component link of a bundled TE link. In this case, the
identifier (numbered or unnumbered) in the main body of the
LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of
which this LSP is a component, and the IPv4 Address field of
this TLV specifies the numbered identifier that is assigned to
this component link within the bundle.
This TLV MUST NOT be present in the same instance of the The IPv6 address that is assigned to this component link within
LSP_TUNNEL_INTERFACE_ID object as a TLV with type 1 (unnumbered the bundle.
component link identifier).
3.6. LSA advertisement 3.4. Link State Advertisement
The ingress and egress LSRs MAY advertise link state associated The ingress and egress of an LSP that is set up using the
with TE links created as described above. The link state may be LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP as agreed in
advertised in either the same IGP instance as used to compute the parameters of the object.
and signal the path for the LSPs that support the TE links, or
another IGP instance. In the former case, the address space for Where a TE link is created from the LSP, the TE link SHOULD inherit
the link state MUST be the same as that used to establish the the TE properties of the LSP as described in [RFC5212] but this
LSPs. In the latter case, the address space for the link state process is subject to local and network-wide policy.
MAY be different, which means that addresses already allocated
in the IGP instance used to establish the LSPs MAY be used by It is possible that an LSP will be used to offer capacity and
the advertised TE link without any ambiguity. connectivity to multiple other networks. In this case, multiple
instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in
the same Path and Resv messages. Each instance MUST have a different
IGP Instance Identifier.
Note, however, that 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 such an object is present, all other instances of the
LSP_TUNNEL_INTERFACE_ID object MUST include an IGP Instance
Identifier TLV with IGP Instance Identifier set to a value that
identifies some other IGP instance (in particular, not the value
0xffffffff).
If the link created from an LSP is advertised in the same IGP
instance as was used to advertise the TE links that the LSP
traverses, the addresses for the new link and that for the links it
is built from MUST come from the same address space.
If the link is advertised into another IGP instance the addresses
MAY be drawn from overlapping address spaces such that some addresses
have different meanings in each IGP instance.
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 Tunnel Sender Address in the Sender Template object signaled in the
assumed that the ingress LSR knows the TE Router ID of the Path message. It is assumed that the ingress LSR knows the TE Router
egress LSR since it has chosen to establish an LSP to that LSR ID of the egress LSR since it has chosen to establish an LSP to that
and plans to use the LSP as a TE link. LSR and plans to use the LSP as a TE link.
The link interface addresses or link interface identifiers for The link interface addresses or link interface identifiers for the
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 an LSP is torn down through explicit action (a PathTear message
when the LSA is advertised into a IGP instance different from or a PathErr message with the Path_State_Removed flag set) the
the one used to establish the LSP because the addresses MAY be ingress and egress LSRs SHOULD withdraw the advertisement of any link
allocated in both domains. that the LSP created and that was previously advertised. The link
state advertisement MAY be retained as a virtual link in another
layer network according to network-wide policy [PCE-LAYER].
4. Applicability Statement 3.5. Message Formats
The method is applicable for both hierarchical LSPs [RFC4206] [RFC3477] does not state where in the Path message or Resv message
and LSP stitching [STITCH]. the LSP_TUNNEL_INTERFACE_ID object should be placed.
5. Backward Compatibility Considerations It is RECOMMENDED that new implementations place the
LSP_TUNNEL_INTERFACE_ID objects in the Path message immediately after
the SENDER_TSPEC object, and in the Resv message immediately after
the FILTER_SPEC object.
The method does not impact the method to exchange unnumbered FA All implementations SHOULD be able to handle received messages with
information described in [RFC3477]. That mechanism can be objects in any order as described in [RFC3209].
safely used in combination with the new mechanisms described
here and is functionally equivalent to using the new C-Type
indicating an unnumbered link with target IGP instance
identifier with the Target IGP Instance value set to 0xffffffff.
This method obsoletes the method to exchange the numbered FA 3.6. Error Cases and Non-Acceptance
information described in [RFC4206]. This is not believed to be
an issue as an informal survey indicated that dynamically Error cases and non-acceptance of new object variants caused by back-
signaled numbered FAs had not been deployed. Indeed it was the level implementations are discussed in Section 3.7.
attempt to implement numbered FAs that gave rise to the work on
An egress LSR that receives an LSP_TUNNEL_INTERFACE_ID object may
have cause to reject the parameters carried in the object for a
number of reasons as set out below. In all cases, the egress SHOULD
respond with a PathErr message with the error code as indicated in
the list below. In most cases the error will arise during LSP setup,
no Resv state will exist, and the PathErr will cause Path state to be
removed. Where the error arises after the LSP has been successfully
set up, the PathErr SHOULD be sent with the Path_State_Removed flag
[RFC3473] clear so that the LSP remains operational.
The error cases identified are as follows and are reported using the
new error code 'LSP Hierarchy Issue' (code 34 TBD by IANA) and the
error values listed below.
Error | Error | Error-case
code | value |
------+-------+------------------------------------------------------
34 1 Link advertisement not supported
34 2 Link advertisement not allowed by policy
34 3 TE link creation not supported
34 4 TE link creation not allowed by policy
34 5 Routing adjacency creation not supported
34 6 Routing adjacency creation not allowed by policy
34 7 Bundle creation not supported
34 8 Bundle creation not allowed by policy
34 9 Hierarchical LSP not supported
34 10 LSP stitching not supported
34 11 Link address type or family not supported
34 12 IGP instance unknown
34 13 IGP instance advertisement not allowed by policy
34 14 Component link identifier not valid
34 15 Unsupported component link identifier address family
When an ingress LSR receives an LSP_TUNNEL_INTERFACE_ID object on a
Resv message it may need to reject it because of the setting of
certain parameters in the object. Since these reasons all represent
errors rather than negotiable parameter-mismatches, the ingress
SHOULD respond with a PathTear to remove the LSP. The ingress MAY use
a ResvErr with one of the following error codes, allowing the egress
the option to correct the error in a new Resv message, or to tear the
LSP with a PathErr with Path_State_Removed flag set. An ingress that
uses the ResvErr MUST take precautions against a protocol loop where
the egress responds with the same LSP_TUNNEL_INTERFACE_ID object with
the same or different) issues.
Error | Error | Error-case
code | value |
------+-------+------------------------------------------------------
34 11 Link address type or family not supported
34 14 Component link identifier not valid
34 15 Unsupported component link identifier address family
34 16 Component link identifier missing
3.7. Backward Compatibility
The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class
number of 193. According to [RFC2205], this means that a node that
does not understand the object SHOULD ignore the object but forward
it, unexamined and unmodified. Thus there are no issues with transit
LSRs supporting the pre-existing or new Class Types of this object.
A back-level ingress node will behave as follows:
- It will not issue Path messages containing LSP_TUNNEL_INTERFACE_ID
objects with the new Class Types defined in this document.
- It will reject Resv messages containing LSP_TUNNEL_INTERFACE_ID
objects with the new Class Types defined in this document as
described in [RFC2205]. In any case, such a situation would
represent an error by the egress.
- It will continue to use the LSP_TUNNEL_INTERFACE_ID object with
Class Type 1 as defined in [RFC3477]. This behavior is supported by
back-level egresses and by egresses conforming to this document.
- According to an informal survey, there is no significant deployment
of numbered FA establishment following the procedures defined in
[RFC4206] and set out in Section 1.3.6 of this document. It is
therefore safe to assume that back-level ingress LSRs will not use
this mechanism.
A back-level egress node will behave as follows:
- It will continue to support the LSP_TUNNEL_INTERFACE_ID object with
Class Type 1 as defined in [RFC3477] if issued by an ingress.
- It will reject a Path message that carries an
LSP_TUNNEL_INTERFACE_ID object with any of the new Class Types
defined in this document using the procedures of [RFC2205]. This
will inform the ingress that the egress is a back-level LSR.
- It will not expect to use the procedures for numbered FA
establishment defined in [RFC4206] and set out in Section 1.3.6 of
this document. this document.
6. Security Considerations In summary, the new mechanisms defined in this document do not impact
the method to exchange unnumbered FA information described in
[RFC3477]. That mechanism can be safely used in combination with the
new mechanisms described here and is functionally equivalent to using
the new C-Type indicating an unnumbered link with target IGP instance
identifier with the Target IGP Instance value set to 0xffffffff.
[RFC3477] points out that one can argue that the use of the The mechanisms in this document obsolete the method to exchange the
extra interface identifier that it provides could make an RSVP numbered FA information described in [RFC4206] as described in
message harder to spoof. In that respect, the minor extensions Section 1.4.6.
to the protocol made in this document do not constitute an
additional security risk, but could also be said to improve
security.
It should be noted that the ability of an ingress LSR to request 4. Security Considerations
that 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 MUST NOT automatically accept the word of the ingress
unless it is configured with such a policy.
7. IANA Considerations [RFC3477] points out that one can argue that the use of the extra
interface identifier that it provides could make an RSVP message
harder to spoof. In that respect, the minor extensions to the
protocol made in this document do not constitute an additional
security risk, but could also be said to improve security.
This document defines three new C-Types for the It should be noted that the ability of an ingress LSR to request that
LSP_TUNNEL_INTERFACE_ID object. The C-Types for this object are an egress LSR advertise an LSP as a TE link MUST be subject to
managed by IANA, and IANA is requested to assign values to the appropriate policy checks at the egress LSR. That is, the egress LSR
new C-Types as tabulated in section 2.2 and described in MUST NOT automatically accept the word of the ingress unless it is
sections 2.2.2, 2.2.3 and 2.2.4. configured with such a policy.
8. Acknowledgement Further details of security for MPLS-TE and GMPLS can be found in
[GMPLS-SEC].
The authors would like to thank John Drake and Yakov Rekhter for 5. IANA Considerations
their valuable discussions and comments.
Funding for the RFC Editor function is currently provided by the
Internet Society.
9. References 5.1. New Class Types
9.1. Normative References IANA maintains a registry of RSVP parameters called "Resource
Reservation Protocol (RSVP) Parameters" with a sub-registry called
"Class Names, Class Numbers, and Class Types." There is an entry in
this registry for the LSP_TUNNEL_INTERFACE_ID object defined in
[RFC3477] with one Class Type defined.
IANA is requested to allocate three new Class Types for this object
as defined in Sections 3.1.2, 3.1.3, and 3.1.4 as follows:
C-Type Meaning Reference
---------------------------------------------------------------
2 IPv4 interface identifier with target [This.doc]
3 IPv6 interface identifier with target [This.doc]
4 Unnumbered interface with target [This.doc]
5.2. Hierarchy Actions
Section 3.1.2 defines an 8-bit flags field in the
LSP_TUNNEL_INTERFACE_ID object. IANA is requested to create a new
sub-registry of the "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Parameters" registry called the "Hierarchy Actions"
sub-registry as follows:
Registry Name: Hierarchy Actions
Reference: [This.doc]
Registration Procedures: IETF Standards Action RFC
Registry:
Bit Number Hex Value Name Reference
---------- ----------- ----------------------- ---------
0-2 Unassigned
3 0x10 Hierarchy/stitching (H) [This.doc]
4 0x08 Bundle (B) [This.doc]
5 0x04 Routing adjacency(R) [This.doc]
6 0x02 TE link (T) [This.doc]
7 0x01 Private (P) [This.doc]
5.3. New Error Codes and Error Values
IANA maintains a registry of RSVP error codes and error values as the
"Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry
of the "Resource Reservation Protocol (RSVP) Parameters" registry.
IANA is requested to define a new error code with suggested value 34
as below (see also Section 3.6).
Error Code Meaning
34 LSP Hierarchy Issue [This.doc]
IANA is requested to list the following error values for this error
code (see also Section 3.6).
This Error Code has the following globally-defined Error
Value sub-codes:
1 = Link advertisement not supported [This.doc]
2 = Link advertisement not allowed by policy [This.doc]
3 = TE link creation not supported [This.doc]
4 = TE link creation not allowed by policy [This.doc]
5 = Routing adjacency creation not supported [This.doc]
6 = Routing adjacency creation not allowed by policy [This.doc]
7 = Bundle creation not supported [This.doc]
8 = Bundle creation not allowed by policy [This.doc]
9 = Hierarchical LSP not supported [This.doc]
10 = LSP stitching not supported [This.doc]
11 = Link address type or family not supported [This.doc]
12 = IGP instance unknown [This.doc]
13 = IGP instance advertisement not allowed by policy [This.doc]
14 = Component link identifier not valid [This.doc]
15 = Unsupported component link identifier address [This.doc]
family
16 = Component link identifier missing [This.doc]
6. Acknowledgements
The authors would like to thank John Drake, Yakov Rekhter, and Igor
Bryskin for their valuable discussions and comments.
7. References
7.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.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[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 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
Links in Resource ReSerVation Protocol - Traffic Switching (MPLS) Signaling Resource ReserVation Protocol
Engineering (RSVP-TE)", RFC 3477, January 2003. Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC4201]Kompella, K., Rekhter, Y., and Berger, L.," Link [RFC3477] Kompella, K. and Rekhter, Y., "Signalling Unnumbered Links
Bundling in MPLS Traffic Engineering (TE)", RFC 4201, in Resource ReSerVation Protocol - Traffic Engineering
October 2005. (RSVP-TE)", RFC 3477, January 2003.
[RFC4201] Kompella, K., Rekhter, Y., and Berger, L.," Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with [RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
Generalized MPLS TE", RFC 4206, October 2005. Generalized MPLS TE", RFC 4206, October 2005.
[STITCH] Ayyangar, A. and J.P. Vasseur, "Label Switched Path [RFC5150] Ayyangar, A., Vasseur, J.P, and Farrel, A., "Label Switched
Stitching with Generalized MPLS Traffic Engineering", Path Stitching with Generalized Multiprotocol Label
draft-ietf-ccamp-lsp-stitching, (work in progress). Switching Traffic Engineering (GMPLS TE)", RFC 5150,
February 2008.
9.2. Informative References 7.2. Informative References
[RFC3630]Katz, D., Kompella, K. and Yeung, D., "Traffic [RFC1195] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and
Engineering (TE) Extensions to OSPF Version 2", RFC dual environments", RFC 1195, December 1990
3630, September 2003.
[RFC4105]Le Roux, J.-L., Vassuer, J.-P., and Boyle, J. (Eds.), [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
"Requirements for Inter-Area MPLS Traffic Engineering", September 1991.
RFC 4105, June 2005.
[RFC4204]Lang, J. (Ed.), "Link Management Protocol (LMP)", [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
RFC 4204, October 2005.
[RFC4726]Farrel, A., Vasseur, J.-P., and Ayyangar, A., " A [RFC3630] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering
Framework for Inter-Domain Multiprotocol Label (TE) Extensions to OSPF Version 2", RFC 3630, September
Switching Traffic Engineering ", RFC 4726, November 2003.
2006.
[MLN-REQ]Shiomoto, K., et al, "Requirements for GMPLS-based [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions
multi-region and multi-layer networks (MRN/MLN)", in Support of Generalized Multi-Protocol Label Switching
draft-ietf-ccamp-gmpls-mln-reqs, (work in progress). (GMPLS)", RFC 4202, October 2005.
[PCE-INTER-LAYER-REQ] Oki, E. (Ed.), " PCC-PCE Communication [RFC4203] Kompella, K. Ed. and Y. Rekhter, Ed., "OSPF Extensions in
and PCE Discovery Requirements for Inter-Layer Traffic Support of Generalized Multi-Protocol Label Switching
Engineering ", draft-ietf-pce-inter-layer-req, (work in (GMPLS)", RFC 4203, October 2005.
progress).
Author's Addresses [RFC5212] Shiomoto, K., et al, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July
2008
[RFC5305] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 5305, October 2008.
[RFC5307] Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate System
to Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", RFC
5307, October 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
2008.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and Lindem, A.,
(Ed.), "Traffic Engineering Extensions to OSPF version 3",
RFC 5329, September 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for
IPv6", RFC 5340, July 2008.
[GMPLS-SEC] Fang, L., et al., "Security Framework for MPLS and GMPLS
Networks", draft-ietf-mpls-mpls-and-gmpls-security-
framework, work in progress.
[ISIS-GENAP] Ginsberg, L., Previdi, S., and Shand, M., "Advertising
Generic Information in IS-IS", draft-ietf-isis-genapp, work
in progress.
[ISIS-IPV6-TE] Harrison, J., Berger, J., and Bartlett, M., "IPv6
Traffic Engineering in IS-IS", draft-ietf-isis-ipv6-te,
work in progress.
[OSPF-TI] Lindem, A., Roy, A., and Mirtorabi, S., "OSPF Transport
Instance Extensions", draft-acee-ospf-transport-instance,
work in progress.
[OSPFv2-MI] Lindem, A., Roy, A., and Mirtorabi, S., "OSPF Multi-
Instance Extensions", draft-acee-ospf-multi-instance, work
in progress.
[PCE-LAYER] Oki, E. (Ed.), "PCC-PCE Communication and PCE Discovery
Requirements for Inter-Layer Traffic Engineering", draft-
ietf-pce-inter-layer-req, (work in progress).
8. Editors' 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
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
9. Authors' Addresses
Richard Rabbat Richard Rabbat
Google Inc. Google Inc.
1600 Amphitheatre Pkwy
Mountain View, CA 94043
Email: rabbat@alum.mit.edu Email: rabbat@alum.mit.edu
Arthi Ayyangar Arthi Ayyangar
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
United States of America United States of America
Phone:
Email: arthi@juniper.net Email: arthi@juniper.net
Adrian Farrel
Old Dog Consulting
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 The IETF takes no position regarding the validity or scope of any
any Intellectual Property Rights or other rights that might be Intellectual Property Rights or other rights that might be claimed to
claimed to pertain to the implementation or use of the pertain to the implementation or use of the technology described in
technology described in this document or the extent to which any this document or the extent to which any license under such rights
license under such rights might or might not be available; nor might or might not be available; nor does it represent that it has
does it represent that it has made any independent effort to made any independent effort to identify any such rights. Information
identify any such rights. Information on the procedures with on the procedures with respect to rights in RFC documents can be
respect to rights in RFC documents can be found in BCP 78 and found in BCP 78 and BCP 79.
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 attempt made to obtain a general license or permission for the use of
use of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR specification can be obtained from the IETF on-line IPR repository at
repository at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention any
any copyrights, patents or patent applications, or other copyrights, patents or patent applications, or other proprietary
proprietary rights that may cover technology that may be rights that may cover technology that may be required to implement
required to implement this standard. Please address the this standard. Please address the information to the IETF at
information to the IETF at ietf-ipr@ietf.org ietf-ipr@ietf.org.
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject Copyright (C) The IETF Trust (2008). This document is subject to the
to the rights, licenses and restrictions contained in BCP 78, rights, licenses and restrictions contained in BCP 78, and except as
and except as set forth therein, the authors retain all their set forth therein, the authors retain all their rights.
rights.
This document and the information contained herein are provided This document and the information contained herein are provided on an
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 183 change blocks. 
712 lines changed or deleted 1087 lines changed or added

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