draft-ietf-ccamp-lsp-hierarchy-bis-08.txt   rfc6107.txt 
Network Working Group K. Shiomoto (Ed.)
Internet Draft NTT
Updates: 3477, 4206 A. Farrel (Ed.)
Proposed Category: Proposed Standard Old Dog Consulting
Created: February 27, 2010
Expires: August 27, 2010
Procedures for Dynamically Signaled Internet Engineering Task Force (IETF) K. Shiomoto, Ed.
Hierarchical Label Switched Paths Request for Comments: 6107 NTT
Updates: 3477, 4206 A. Farrel, Ed.
Category: Standards Track Old Dog Consulting
ISSN: 2070-1721 February 2011
draft-ietf-ccamp-lsp-hierarchy-bis-08.txt Procedures for Dynamically Signaled Hierarchical Label Switched Paths
Abstract Abstract
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching Label Switched Paths (LSPs) set up in Multiprotocol Label Switching
(MPLS) or Generalized MPLS (GMPLS) networks can be used to form links (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links
to carry traffic in those networks or in other (client) networks. to carry traffic in those networks or in other (client) networks.
Protocol mechanisms already exist to facilitate the establishment of Protocol mechanisms already exist to facilitate the establishment of
such LSPs and to bundle TE links to reduce the load on routing such LSPs and to bundle traffic engineering (TE) links to reduce the
protocols. This document defines extensions to those mechanisms to load on routing protocols. This document defines extensions to those
support identifying the use to which such LSPs are to be put and to mechanisms to support identifying the use to which such LSPs are to
enable the TE link endpoints to be assigned addresses or unnumbered be put and to enable the TE link endpoints to be assigned addresses
identifiers during the signaling process. or unnumbered identifiers during the signaling process.
The mechanisms defined in this document deprecates the technique The mechanisms defined in this document deprecate the technique for
for the signaling of LSPs that are to be used as numbered TE links the signaling of LSPs that are to be used as numbered TE links
described in RFC 4206. described in RFC 4206.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This is an Internet Standards Track document.
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/ietf/1id-abstracts.txt. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6107.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction and Problem Statement ............................. 3 1. Introduction and Problem Statement ..............................3
1.1. Background ................................................... 4 1.1. Background .................................................4
1.1.1. Hierarchical LSPs .......................................... 4 1.1.1. Hierarchical LSPs ...................................4
1.1.2. LSP Stitching Segments ..................................... 5 1.1.2. LSP Stitching Segments ..............................5
1.1.3. Private Links .............................................. 5 1.1.3. Private Links .......................................5
1.1.4. Routing Adjacencies ........................................ 5 1.1.4. Routing Adjacencies .................................5
1.1.5. Forwarding Adjacencies ..................................... 5 1.1.5. Forwarding Adjacencies ..............................5
1.1.6. Client/Server Networks ..................................... 6 1.1.6. Client/Server Networks ..............................6
1.1.7. Link Bundles ............................................... 6 1.1.7. Link Bundles ........................................6
1.2. Desired Function ............................................. 6 1.2. Desired Function ...........................................7
1.3. Existing Mechanisms .......................................... 7 1.3. Existing Mechanisms ........................................7
1.3.1. LSP Setup .................................................. 7 1.3.1. LSP Setup ...........................................7
1.3.2. Routing Adjacency Establishment and Link State Advertisement 7 1.3.2. Routing Adjacency Establishment and Link
1.3.3. TE Link Advertisement ...................................... 7 State Advertisement .................................7
1.3.4. Configuration and Management Techniques .................... 7 1.3.3. TE Link Advertisement ...............................7
1.3.5. Signaled Unnumbered FAs .................................... 8 1.3.4. Configuration and Management Techniques .............8
1.3.6. Establishing Numbered FAs Through Signaling and Routing .... 9 1.3.5. Signaled Unnumbered FAs .............................8
1.4. Overview of Required Extensions ............................. 10 1.3.6. Establishing Numbered FAs through Signaling
1.4.1. Efficient Signaling of Numbered FAs ....................... 10 and Routing .........................................9
1.4.2. LSPs for Use as Private Links ............................. 10 1.4. Overview of Required Extensions ...........................10
1.4.3. Signaling an LSP For use in Another Network ............... 10 1.4.1. Efficient Signaling of Numbered FAs ................10
1.4.4. Signaling an LSP for Use in a Link Bundle ................. 10 1.4.2. LSPs for Use as Private Links ......................10
1.4.5. Support for IPv4 and IPv6 ................................. 11 1.4.3. Signaling an LSP for Use in Another Network ........10
1.4.6. Backward Compatibility .................................... 11 1.4.4. Signaling an LSP for Use in a Link Bundle ..........11
2. Overview of Solution .......................................... 11 1.4.5. Support for IPv4 and IPv6 ..........................11
2.1. Common Approach for Numbered and Unnumbered Links ........... 11 1.4.6. Backward Compatibility .............................11
2.2. LSP Usage Indication ........................................ 11 2. Overview of Solution ...........................................11
2.3. IGP Instance Identification ................................. 11 2.1. Common Approach for Numbered and Unnumbered Links .........11
2.4. Link Bundle Identification .................................. 12 2.2. LSP Usage Indication ......................................12
2.5. Backward Compatibility ...................................... 12 2.3. IGP Instance Identification ...............................12
3. Mechanisms and Protocol Extensions ............................ 12 2.4. Link Bundle Identification ................................12
3.1. LSP_TUNNEL_INTERFACE_ID Object .............................. 12 2.5. Backward Compatibility ....................................12
3.1.1. Existing Definition and Usage ............................. 12 3. Mechanisms and Protocol Extensions .............................13
3.1.2. Unnumbered Links with Action Identification ............... 13 3.1. LSP_TUNNEL_INTERFACE_ID Object ............................13
3.1.3. IPv4 Numbered Links with Action Identification ............ 15 3.1.1. Existing Definition and Usage ......................13
3.1.4. IPv6 Numbered Links with Action Identification ............ 16 3.1.2. Unnumbered Links with Action Identification ........13
3.2. Target IGP Identification TLV ............................... 17 3.1.3. IPv4 Numbered Links with Action Identification .....16
3.3. Component Link Identification TLV ........................... 19 3.1.4. IPv6 Numbered Links with Action Identification .....17
3.3.1. Unnumbered Component Link Identification .................. 19 3.2. Target IGP Identification TLV .............................18
3.3.2. IPv4 Numbered Component Link Identification ............... 19 3.3. Component Link Identification TLV .........................19
3.3.3. IPv6 Numbered Component Link Identification ............... 20 3.3.1. Unnumbered Component Link Identification ...........20
3.4. Link State Advertisement .................................... 20 3.3.2. IPv4 Numbered Component Link Identification ........20
3.5. Message Formats ............................................. 21 3.3.3. IPv6 Numbered Component Link Identification ........21
3.6. Error Cases and Non-Acceptance .............................. 22 3.4. Link State Advertisement ..................................21
3.7. Backward Compatibility ...................................... 23 3.5. Message Formats ...........................................22
4. Security Considerations ....................................... 24 3.6. Error Cases and Non-Acceptance ............................22
5. IANA Considerations ........................................... 24 3.7. Backward Compatibility ....................................24
5.1. New Class Types ............................................. 24 4. Security Considerations ........................................25
5.2. Hierarchy Actions ........................................... 25 5. IANA Considerations ............................................25
5.3. New Error Codes and Error Values ............................ 25 5.1. New Class Types ...........................................25
6. Acknowledgements .............................................. 26 5.2. Hierarchy Actions .........................................26
7. References .................................................... 26 5.3. New Error Codes and Error Values ..........................26
7.1. Normative References ........................................ 26 6. Acknowledgements ...............................................27
7.2. Informative References ...................................... 27 7. References .....................................................27
8. Editors' Addresses ............................................ 28 7.1. Normative References ......................................27
9. Authors' Addresses ............................................ 29 7.2. Informative References ....................................28
1. Introduction and Problem Statement 1. Introduction and Problem Statement
Traffic Engineering (TE) links in a Multiprotocol Label Switching Traffic Engineering (TE) links in a Multiprotocol Label Switching
(MPLS) or a Generalized MPLS (GMPLS) network may be constructed from (MPLS) or a Generalized MPLS (GMPLS) network may be constructed from
Label Switched Paths (LSPs) [RFC4206]. Such LSPs are known as Label Switched Paths (LSPs) [RFC4206]. Such LSPs are known as
hierarchical LSPs (H-LSPs). hierarchical LSPs (H-LSPs).
The LSPs established in one network may be used as TE links in The LSPs established in one network may be used as TE links in
another network, and this is particularly useful when a server layer another network, and this is particularly useful when a server layer
network (for example, an optical network) provides LSPs for use as TE network (for example, an optical network) provides LSPs for use as TE
links in a client network (for example, a packet network). This links in a client network (for example, a packet network). This
enables the construction of a multilayer networks (MLN) [RFC5212]. enables the construction of a multilayer network (MLN) [RFC5212].
When the number of TE links (created from LSPs or otherwise) between When the number of TE links (created from LSPs or otherwise) between
a pair of nodes grows large, it is inefficient to advertise them a pair of nodes grows large, it is inefficient to advertise them
individually. This may cause scaling issues in configuration and in individually. This may cause scaling issues in configuration and in
the routing protocols used to carry the advertisements. The solution the routing protocols used to carry the advertisements. The solution
(described in [RFC4201]) is to collect the TE links together and to (described in [RFC4201]) is to collect the TE links together and to
advertise them as a single TE link called a link bundle. advertise them as a single TE link called a link bundle.
These various mechanisms have proved to be very powerful in building These various mechanisms have proved to be very powerful in building
dynamically provisioned networks, but, as set out later in this dynamically provisioned networks, but, as set out later in this
document, several issues have been identified during deployment with document, several issues have been identified during deployment with
how LSPs are established and made available for use as H-LSPs or as how LSPs are established and made available for use as H-LSPs or as
components of a link bundle, and with how these links are advertised components of a link bundle, and with how these links are advertised
appropriately in an interior gateway protocol (IGP). These issues appropriately in an interior gateway protocol (IGP). These issues
relate to coordinating between the LSP's end points the use to which relate to how the LSP's endpoints coordinate two things: the use to
the LSP is put, and the allocation of the identifiers of the end which the LSP is put and the identifiers of the endpoints.
points.
This document provides solutions to the issues by defining mechanisms This document provides solutions to these issues by defining
so that the ends of signaled LSPs can exchange information about: mechanisms so that the ends of signaled LSPs can exchange information
about:
- Whether the LSP is an ordinary LSP or an H-LSP. - Whether the LSP is an ordinary LSP or an H-LSP.
- In which IGP instances the LSP should be advertised as a link. - In which IGP instances the LSP should be advertised as a link.
- How the client networks should make use of the new links. - How the client networks should make use of the new links.
- Whether the link should form part of a bundle (and if so, which). - Whether the link should form part of a bundle (and if so, which
- How the link end points should be identified when advertised. bundle).
- How the link endpoints should be identified when advertised.
This document deprecates one of the mechanisms defined in [RFC4206] This document deprecates one of the mechanisms defined in [RFC4206]
for the signaling of LSPs that are to be used as numbered TE links for the signaling of LSPs that are to be used as numbered TE links
(see Sections 1.3.6 and 1.4.6 for more details), and provides (see Sections 1.3.6 and 1.4.6 for more details), and provides
extensions to the other mechanisms defined in [RFC4206] so that the extensions to the other mechanisms defined in [RFC4206] so that the
use to which the new LSP is to be put may be indicated during use to which the new LSP is to be put may be indicated during
signaling. It also extends the mechanisms defined in [RFC3477] for signaling. It also extends the mechanisms defined in [RFC3477] for
signaling unnumbered TE links. signaling unnumbered TE links.
1.1. Background The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.1.1. Hierarchical LSPs 1.1. Background
[RFC3031] describes how Multiprotocol Label Switching (MPLS) labels 1.1.1. Hierarchical LSPs
may be stacked so that LSPs may be nested with one LSP running
through another. This concept of H-LSPs is formalized in [RFC4206] [RFC3031] describes how MPLS labels may be stacked so that LSPs may
with a set of protocol mechanisms for the establishment of an H-LSP be nested with one LSP running through another. This concept of
that can carry one or more other LSPs. H-LSPs is formalized in [RFC4206] with a set of protocol mechanisms
for the establishment of an H-LSP that can carry one or more other
LSPs.
[RFC4206] goes on to explain that an H-LSP may carry other LSPs only [RFC4206] goes on to explain that an H-LSP may carry other LSPs only
according to their switching types. This is a function of the way according to their switching types. This is a function of the way
labels are carried. In a packet switch capable (PSC) network, the 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- 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 packet networks where the label is implicit, label stacks are not
possible, and H-LSPs rely on the ability to nest switching possible, and H-LSPs rely on the ability to nest switching
technologies. Thus, for example, a lambda switch capable (LSC) LSP technologies. Thus, for example, a lambda switch capable (LSC) LSP
can carry a time division multiplexing (TDM) LSP, but cannot carry can carry a time-division multiplexing (TDM) LSP, but cannot carry
another LSC LSP. another LSC LSP.
Signaling mechanisms defined in [RFC4206] allow an H-LSP to be 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 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- the LSP carried by the H-LSP). This mechanism is known as "non-
adjacent signaling." adjacent signaling".
1.1.2. LSP Stitching Segments 1.1.2. LSP Stitching Segments
LSP stitching is defined in [RFC5150]. It enables LSPs of the same LSP stitching is defined in [RFC5150]. It enables LSPs of the same
switching type to be included (stitched) as hops in an end-to-end switching type to be included (stitched) as hops in an end-to-end
LSP. The stitching LSP (S-LSP) is used in the control plane in the 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 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 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 S-LSP must be of the same switching technology as the end-to-end LSP
that it facilitates. that it facilitates.
1.1.3. Private Links 1.1.3. Private Links
An H-LSP or S-LSP can be used as a private link. Such links are known An H-LSP or S-LSP can be used as a private link. Such links are
by their end-points, but are not more widely known and are not known by their endpoints, but are not more widely known and are not
advertised by routing protocols. They can be used to carry traffic advertised by routing protocols. They can be used to carry traffic
between the end-points, but are not usually used to carry traffic between the endpoints, but are not usually used to carry traffic that
that is going beyond the egress of the LSP. is going beyond the egress of the LSP.
1.1.4. Routing Adjacencies 1.1.4. Routing Adjacencies
A routing adjacency is formed between two IGP-speakers that are A routing adjacency is formed between two IGP speakers that are
logically adjacent. In this sense, 'logically adjacent' means that logically adjacent. In this sense, 'logically adjacent' means that
the routers have a protocol tunnel between them through which they the routers have a protocol tunnel between them through which they
can exchange routing protocol messages. The tunnel is also usually can exchange routing protocol messages. The tunnel is also usually
available for carrying IP data although a distinction should be made available for carrying IP data although a distinction should be made
in GMPLS networks between data plane traffic and control plane in GMPLS networks between data-plane traffic and control-plane
traffic. traffic.
Routing adjacencies for forwarding data traffic are only relevant in Routing adjacencies for forwarding data traffic are only relevant in
PSC networks (i.e., IP/MPLS networks). PSC networks (i.e., IP/MPLS networks).
1.1.5. Forwarding Adjacencies 1.1.5. Forwarding Adjacencies
A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link
created from an LSP and advertised in the same instance of the created from an LSP and advertised in the same instance of the
control plane that advertises the TE links from which the LSP is control plane that advertises the TE links from which the LSP is
constructed. The LSP itself is called an FA-LSP. constructed. The LSP itself is called an FA-LSP.
Thus, an H-LSP or S-LSP may form an FA such that it is advertised as 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 a TE link in the same instance of the routing protocol as was used to
advertise the TE links that the LSP traverses. advertise the TE links that the LSP traverses.
As observed in [RFC4206] the nodes at the ends of an FA would not As observed in [RFC4206], the nodes at the ends of an FA would not
usually have a routing adjacency. usually have a routing adjacency.
1.1.6. Client/Server Networks 1.1.6. Client/Server Networks
An LSP may be created in one network and used as a link (sometimes An LSP may be created in one network and used as a link (sometimes
called a virtual link) in another networks [RFC5212]. In this case called a virtual link) in another network [RFC5212]. In this case,
the networks are often referred to as server and client networks the networks are often referred to as server and client networks,
respectively. respectively.
The server network LSP is used as an H-LSP or an S-LSP as described The server network LSP is used as an H-LSP or an S-LSP as described
above, but does not form an FA because the client and server networks above, but it does not form an FA because the client and server
run separate instances of the control plane routing protocols. networks run separate instances of the control-plane routing
protocols.
The virtual link may be used in the client network as a private link The virtual link may be used in the client network as a private link
or may be advertised in the client network IGP. Additionally, the or may be advertised in the client network IGP. Additionally, the
link may be used in the client network to form a routing adjacency link may be used in the client network to form a routing adjacency
and/or as a TE link. and/or as a TE link.
1.1.7. Link Bundles 1.1.7. Link Bundles
[RFC4201] recognizes that a pair of adjacent routers may have a large [RFC4201] recognizes that a pair of adjacent routers may have a large
number of TE links that run between them. This can be a considerable 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 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 that must distribute information about each of them. A TE link
is defined by [RFC4201] as a TE link that is advertised as an 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 aggregate of multiple TE links that could have been advertised in
their own right. All TE links that are collected into a TE link their own right. All TE links that are collected into a TE link
bundle have the same TE properties. bundle have the same TE properties.
Thus, a link bundle is a shorthand that improves the scaling Thus, a link bundle is a shorthand that improves the scaling
properties of the network. properties of the network.
Since a TE link may, itself, be an LSP (either an FA or a virtual Since a TE link may, itself, be an LSP (either an FA or a virtual
link), a link bundle may be constructed from FA-LSPs or virtual link), a link bundle may be constructed from FA-LSPs or virtual
links. links.
1.2. Desired Function 1.2. Desired Function
It should be possible to signal an LSP and automatically coordinate It should be possible to signal an LSP and automatically coordinate
its use and advertisement in any of the ways described in Section 1.3 its use and advertisement in any of the ways described in Section 1.3
with minimum involvement from an operator. The mechanisms used should with minimum involvement from an operator. The mechanisms used
be applicable to numbered and unnumbered links, and should not should be applicable to numbered and unnumbered links and should not
require implementation complexities. require implementation complexities.
1.3. Existing Mechanisms 1.3. Existing Mechanisms
This section briefly introduces existing protocol mechanisms used to This section briefly introduces existing protocol mechanisms used to
satisfy the desired function described in Section 1.2. satisfy the desired function described in Section 1.2.
1.3.1. LSP Setup 1.3.1. LSP Setup
Both unidirectional LSPs and bidirectional LSPs are signaled from the Both unidirectional LSPs and bidirectional LSPs are signaled from the
ingress label switching router (LSR) to the egress LSR. That is, the ingress label switching router (LSR) to the egress LSR. That is, the
ingress LSR is the initiator, and the egress learns about the LSP ingress LSR is the initiator, and the egress learns about the LSP
through the signaling protocol [RFC3209], [RFC3473]. through the signaling protocol [RFC3209] [RFC3473].
1.3.2. Routing Adjacency Establishment and Link State Advertisement 1.3.2. Routing Adjacency Establishment and Link State Advertisement
Although hosts can discover routers (for example through ICMP Although hosts can discover routers (for example, through ICMP
[RFC1256]), routing adjacencies are usually configured at both ends [RFC1256]), routing adjacencies are usually configured at both ends
of the adjacency. This requires that each router know the identity of the adjacency. This requires that each router know the identity
of the router at the other end of the link connecting the routers, of the router at the other end of the link connecting the routers,
and know that the IGP is to be run on this link. and know that the IGP is to be run on this link.
Once a routing adjacency has been established, a pair of routers may Once a routing adjacency has been established, a pair of routers may
use the IGP to share information about the links available for use the IGP to share information about the links available for
carrying IP traffic in the network. carrying IP traffic in the network.
Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version
3 [RFC5340], and IS-IS [RFC1195]. 3 [RFC5340], and IS-IS [RFC1195].
1.3.3. TE Link Advertisement 1.3.3. TE Link Advertisement
Extensions have been made to IGPs to advertise TE link properties Extensions have been made to IGPs to advertise TE link properties
([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]) and ([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]) and
also to advertise link properties in GMPLS networks ([RFC4202], also to advertise link properties in GMPLS networks ([RFC4202],
[RFC4203], and [RFC5307]). [RFC4203], and [RFC5307]).
TE link advertisement can be performed by the same instance of the 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 IGP as is used for normal link state advertisement, or can use a
separate instance. Furthermore, the ends of a TE link advertised in separate instance. Furthermore, the ends of a TE link advertised in
an IGP do not need to form a routing adjacency. This is particularly an IGP do not need to form a routing adjacency. This is particularly
the case with FAs as described in Section 1.1.5. the case with FAs as described in Section 1.1.5.
1.3.4. Configuration and Management Techniques 1.3.4. Configuration and Management Techniques
LSPs are usually created as the result of a management action. This LSPs are usually created as the result of a management action. This
is true even when a control plane is used: the management action is a is true even when a control plane is used: the management action is a
request to the control plane to signal the LSP. request to the control plane to signal the LSP.
If the LSP is to be used as an H-LSP or S-LSP, management commands If the LSP is to be used as an H-LSP or S-LSP, management commands
can be used to install the LSP as a link. The link must be defined, can be used to install the LSP as a link. The link must be defined,
interface identifiers allocated, and the end points configured to interface identifiers allocated, and the endpoints configured to know
know about (and advertise, if necessary) the new link. about (and advertise, if necessary) the new link.
If the LSP is to be used as part of a link bundle, the operator must If the LSP is to be used as part of a link bundle, the operator must
decide which bundle it forms part of and ensure that information is decide which bundle it forms part of and ensure that information is
configured at the ingress and egress, along with the necessary configured at the ingress and egress, along with the necessary
interface identifiers. interface identifiers.
These mechanisms are perfectly functional and quite common in MLNs, These mechanisms are perfectly functional and quite common in MLNs,
but require configuration coordination and additional management. but require configuration coordination and additional management.
They are open to user error and misconfiguration that might result in 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 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. available in the wrong way with some impact on traffic engineering.
1.3.5. Signaled Unnumbered FAs 1.3.5. Signaled Unnumbered FAs
[RFC3477] describes how to establish an LSP and to make it available [RFC3477] describes how to establish an LSP and to make it available
automatically as a TE link in the same instance of the routing automatically as a TE link in the same instance of the routing
protocol as advertises the TE links it traverses, using IPv4-based protocol as advertises the TE links it traverses, using IPv4-based
unnumbered identifiers to identify the new TE link. That is, unnumbered identifiers to identify the new TE link. That is,
[RFC3477] describes how to create an unnumbered FA. [RFC3477] describes how to create an unnumbered FA.
The mechanism, as defined in Section 3 of [RFC3477], is briefly as The mechanism, as defined in Section 3 of [RFC3477], is briefly as
follows: follows:
- The ingress of the LSP signals the LSP as normal using a Path - The ingress of the LSP signals the LSP as normal using a Path
message, and includes an LSP_TUNNEL_INTERFACE_ID object. The message, and includes an LSP_TUNNEL_INTERFACE_ID object. The
LSP_TUNNEL_INTERFACE_ID object identifies: LSP_TUNNEL_INTERFACE_ID object identifies:
- The sender's LSR Router ID - The sender's LSR Router ID
- The sender's interface ID for the TE link being created - The sender's interface ID for the TE link being created
- The egress of the LSP responds as normal to accept the LSP and set - 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 it up, and includes an LSP_TUNNEL_INTERFACE_ID object. The
LSP_TUNNEL_INTERFACE_ID object identifies: LSP_TUNNEL_INTERFACE_ID object identifies:
- The egress's LSR Router ID - The egress's LSR Router ID
- The egress's interface ID for the TE link being created. - The egress's interface ID for the TE link being created.
- Following the exchange of the Path and Resv messages, both the - 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 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 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 advertise the TE links that it traverses, and also know the
unnumbered interface identifiers to use in the advertisement. unnumbered interface identifiers to use in the advertisement.
[RFC3477] does not include mechanisms to support IPv6-based [RFC3477] does not include mechanisms to support IPv6-based
unnumbered identifiers, nor IPv4 or IPv6 numbered identifiers. unnumbered identifiers, nor IPv4 or IPv6 numbered identifiers.
1.3.6. Establishing Numbered FAs Through Signaling and Routing 1.3.6. Establishing Numbered FAs through Signaling and Routing
[RFC4206] describes procedures to establish an LSP and to make it [RFC4206] describes procedures to establish an LSP and to make it
available automatically as a TE link that is identified using IPv4 available automatically as a TE link that is identified using IPv4
addresses in the same instance of the routing protocol as advertised addresses in the same instance of the routing protocol as advertises
the TE links it traverses (that is, as a numbered FA). the TE links it traverses (that is, as a numbered FA).
The mechanism, as defined in [RFC4206], is briefly as follows: The mechanism, as defined in [RFC4206], is briefly as follows:
- The ingress of the LSP signals the LSP as normal using a Path - The ingress of the LSP signals the LSP as normal using a Path
message, and sets the IPv4 tunnel sender address to the IP address message, and sets the IPv4 tunnel sender address to the IP address
it will use to identify its interface for the TE link being it will use to identify its interface for the TE link being
created. This is one address from a /31 pair. created. This is one address from a /31 pair.
- The egress of the LSP responds as normal to accept the LSP and set - The egress of the LSP responds as normal to accept the LSP and set
it up. It infers the address that it must assign to identify its it up. It infers the address that it must assign to identify its
interface for the TE link being created as the partner address of interface for the TE link being created as the partner address of
the /31 pair. the /31 pair.
- The ingress decides whether the LSP is to be advertised as a TE - 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 link (i.e., as an FA). If so, it advertises the link in the IGP in
in the usual way. the usual way.
- If the link is unidirectional, nothing more needs to be done. If - If the link is unidirectional, nothing more needs to be done. If
the link is bidirectional, the egress must also advertise the link, the link is bidirectional, the egress must also advertise the link,
but it does not know that advertisement is required as there is no but it does not know that advertisement is required as there is no
indication in the signaling messages. indication in the signaling messages.
- When the ingress's advertisement of the link is received by the - When the ingress's advertisement of the link is received by the
egress it must check to see whether it is the egress of the LSP egress, it must check to see whether it is the egress of the LSP
that formed the link. Typically this means: that formed the link. Typically, this means the egress:
- Check to see if the link advertisement is new - Checks to see if the link advertisement is new.
- Check to see if the Link-ID address in the received advertisement - Checks to see if the Link-ID address in the received
matches its own TE Router ID advertisement matches its own TE Router ID.
- Checks the advertising router ID from the advertisement against - Checks the advertising router ID from the advertisement against
the ingress address of each LSPs for which it is the egress the ingress address of each LSP for which it is the egress.
- Deduce the LSP that has been advertised as a TE link and issue - Deduces the LSP that has been advertised as a TE link and issues
the corresponding advertisement for the reverse direction. the corresponding advertisement for the reverse direction.
It is possible that some reduction in processing can be achieved by It is possible that some reduction in processing can be achieved by
mapping based on the /31 pairing, but nevertheless, there is a fair mapping based on the /31 pairing, but nevertheless, there is a fair
amount of processing required, and this does not scale well in large amount of processing required, and this does not scale well in large
networks. networks.
Note that this document deprecates this procedure as explained in Note that this document deprecates this procedure as explained in
Section 1.4.6. Section 1.4.6.
No explanation is provided in [RFC4206] of how to create numbered No explanation is provided in [RFC4206] of how to create numbered
IPv6 FAs. IPv6 FAs.
1.4. Overview of Required Extensions 1.4. Overview of Required Extensions
This section provides a brief outline of the required protocol This section provides a brief outline of the required protocol
extensions. extensions.
1.4.1. Efficient Signaling of Numbered FAs 1.4.1. Efficient Signaling of Numbered FAs
The mechanism described in Section 1.3.6. is inefficient. The egress The mechanism described in Section 1.3.6 is inefficient. The egress
must wait until it receives an advertisement from the ingress before must wait until it receives an advertisement from the ingress before
it knows that the LSP is to be installed as a TE link and advertised it knows that the LSP is to be installed as a TE link and advertised
as an FA. Further, it must parse all received advertisements to as an FA. Further, it must parse all received advertisements to
determine if any is the trigger for it to advertise an FA. determine if any is the trigger for it to advertise an FA.
An efficient signaling mechanism is required so that the egress is An efficient signaling mechanism is required so that the egress is
informed by the ingress during LSP establishment. informed by the ingress during LSP establishment.
1.4.2. LSPs for Use as Private Links 1.4.2. LSPs for Use as Private Links
There is currently no mechanism by which an ingress can indicate that There is currently no mechanism by which an ingress can indicate that
an LSP is set up for use as a private link. Any attempt to make it an LSP is set up for use as a private link. Any attempt to make it a
a link would currently cause it to be advertised as an FA. link would currently cause it to be advertised as an FA.
A signaling mechanism is needed to identify the use to which an LSP A signaling mechanism is needed to identify the use to which an LSP
is to be put. is to be put.
1.4.3. Signaling an LSP For use in Another Network 1.4.3. Signaling an LSP for Use in Another Network
The existing signaling/routing mechanisms are designed for use in the The existing signaling/routing mechanisms are designed for use in the
creation of FAs. That is, the TE link created is advertised in the creation of FAs. That is, the TE link created is advertised in the
single IGP instance. single IGP instance.
The numbered TE link mechanism (Section 1.3.6) could, in theory, be 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 used in an MLN with multiple IGP instances if the addressing model is
kept consistent across the networks, and if the egress searches all kept consistent across the networks, and if the egress searches all
advertisements in all IGP instances. But this is complex and does not advertisements in all IGP instances. However, this is complex and
work for unnumbered interfaces. does not work for unnumbered interfaces.
A signaling mechanism is required to indicate in which IGP instance A signaling mechanism is required to indicate in which IGP instance
the TE link should be advertised. the TE link should be advertised.
1.4.4. Signaling an LSP for Use in a Link Bundle 1.4.4. Signaling an LSP for Use in a Link Bundle
A signaling mechanism is required to indicate that an LSP is intended A signaling mechanism is required to indicate that an LSP is intended
to form a component link of a link bundle, and to identify the to form a component link of a link bundle, and to identify the bundle
bundle and the IGP instance in which the bundle is advertised. and the IGP instance in which the bundle is advertised.
1.4.5. Support for IPv4 and IPv6 1.4.5. Support for IPv4 and IPv6
The protocol mechanisms must support IPv4 and IPv6 numbered and The protocol mechanisms must support IPv4 and IPv6 numbered and
unnumbered TE links. unnumbered TE links.
1.4.6. Backward Compatibility 1.4.6. Backward Compatibility
The existing protocol mechanisms for unnumbered FAs as defined in The existing protocol mechanisms for unnumbered FAs as defined in
[RFC4206] and [RFC3477] must continue to be supported, and new [RFC4206] and [RFC3477] must continue to be supported, and new
mechanisms must be devised such that their introduction will not mechanisms must be devised such that their introduction will not
break existing implementations or deployments. break existing implementations or deployments.
Note that an informal survey in the CCAMP working group established Note that an informal survey in the CCAMP working group established
that there are no significant deployments of numbered FAs established that there are no significant deployments of numbered FAs established
using the technique described in [RFC4206] and set out in Section using the technique described in [RFC4206] and set out in Section
1.3.6. Therefore, this document deprecates this procedure. 1.3.6. Therefore, this document deprecates this procedure.
2. Overview of Solution 2. Overview of Solution
This section provides an overview of the mechanisms and protocol This section provides an overview of the mechanisms and protocol
extensions defined in this document. Details are presented in Section extensions defined in this document. Details are presented in
3. Section 3.
2.1. Common Approach for Numbered and Unnumbered Links 2.1. Common Approach for Numbered and Unnumbered Links
The LSP_TUNNEL_INTERFACE_ID object [RFC3477] is extended for use for The LSP_TUNNEL_INTERFACE_ID object [RFC3477] is extended for use for
all H-LSPs and S-LSPs whether they form numbered or unnumbered, IPv4 all H-LSPs and S-LSPs whether they form numbered or unnumbered IPv4
or IPv6 links. Different class-types of the object identify the or IPv6 links. Different Class Types of the object identify the
address type for which it applies. address type for which it applies.
2.2. LSP Usage Indication 2.2. LSP Usage Indication
The LSP_TUNNEL_INTERFACE_ID object is given flags in a new Actions 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 field to say how the LSP is to be used. The following categories are
supported: 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
- The LSP is used as part of a link bundle
- The LSP is used as a hierarchical LSP or a stitching segment
2.3. IGP Instance Identification - The LSP is used as an advertised TE link.
- The LSP is used to form a routing adjacency.
- The LSP is used to form an advertised TE link and a routing
adjacency.
- The LSP forms a private link and is not advertised.
- The LSP is used as part of a link bundle.
- The LSP is used as a hierarchical LSP or a stitching segment.
2.3. IGP Instance Identification
An optional TLV is added to the LSP_TUNNEL_INTERFACE_ID object to An optional TLV is added to the LSP_TUNNEL_INTERFACE_ID object to
identify the IGP instance into which the link formed by the LSP is to 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 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 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 instance of the IGP as was used to advertise the TE links it
traverses. traverses.
2.4. Link Bundle Identification 2.4. Link Bundle Identification
When an LSP is to be used as a component link of a link bundle, the 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 LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how
the bundle is addressed and used, and a new TLV indicates the the bundle is addressed and used, and a new TLV indicates the
component link identifier for the link that the LSP creates. component link identifier for the link that the LSP creates.
2.5. Backward Compatibility 2.5. Backward Compatibility
Backward compatibility has three aspects. Backward compatibility has three aspects.
- Existing mechanisms for unnumbered FAs described in [RFC3477] and - Existing mechanisms for unnumbered FAs described in [RFC3477] and
[RFC4206] must continue to work, so that ingress nodes do not have [RFC4206] must continue to work, so that ingress nodes do not have
to be updated when egresses are updated. to be updated when egresses are updated.
- Existing mechanisms for establishing numbered FAs described in - Existing mechanisms for establishing numbered FAs described in
[RFC4206] are safely deprecated by this document as they are not [RFC4206] are safely deprecated by this document, as they are not
significantly deployed. significantly deployed.
- New mechanisms must be gracefully rejected by existing egress - New mechanisms must be gracefully rejected by existing egress
implementations so that egress nodes do not have to be updated when implementations so that egress nodes do not have to be updated when
ingresses are updated. ingresses are updated.
3. Mechanisms and Protocol Extensions 3. Mechanisms and Protocol Extensions
This section defines protocol mechanisms and extensions to achieve This section defines protocol mechanisms and extensions to achieve
the function described in the previous section. the function described in the previous section.
3.1. LSP_TUNNEL_INTERFACE_ID Object 3.1. LSP_TUNNEL_INTERFACE_ID Object
The principal signaling protocol element used to achieve all of the The principal signaling protocol element used to achieve all of the
required functions is the LSP_TUNNEL_INTERFACE_ID object defined in required functions is the LSP_TUNNEL_INTERFACE_ID object defined in
[RFC3477]. The existing definition and usage continues to be [RFC3477]. The existing definition and usage continues to be
supported as described in the next section. Subsequent sections supported as described in the next section. Subsequent sections
describe new variants of the object (denoted by new Class Types), and describe new variants of the object (denoted by new Class Types), and
additional information carried in the object by means of extensions. additional information carried in the object by means of extensions.
3.1.1. Existing Definition and Usage 3.1.1. Existing Definition and Usage
This document does not deprecate the mechanisms defined in [RFC3477] This document does not deprecate the mechanisms defined in [RFC3477]
and [RFC4206]. Those procedures must continue to operate as described and [RFC4206]. Those procedures must continue to operate as
in Section 3.7. described in Section 3.7.
That means that the LSP_TUNNEL_INTERFACE_ID object with Class Type 1 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 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 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 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 is, as an FA). The procedure is unchanged and operates as summarized
in Section 1.3.5. in Section 1.3.5.
[RFC3477] does not make any suggestions about where in Path or Resv [RFC3477] does not make any suggestions about where in Path or Resv
messages the LSP_TUNNEL_INTERFACE_ID object should be placed. See messages the LSP_TUNNEL_INTERFACE_ID object should be placed. See
Section 3.5 for recommended placement of this object in new Section 3.5 for recommended placement of this object in new
implementations. implementations.
3.1.2. Unnumbered Links with Action Identification 3.1.2. Unnumbered Links with Action Identification
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined
to carry an unnumbered interface identifier and to indicate into to carry an unnumbered interface identifier and to indicate into
which instance of the IGP the consequent TE link should be which instance of the IGP the consequent TE link should be
advertised. This does not deprecate the use of C-Type 1. 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 = 4 (TBD by IANA) C-NUM = 193, C-Type = 4
0 1 2 3
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSR's Router ID |
| LSR's Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) |
| Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Actions | Reserved |
| Actions | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~
~ TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSR's Router ID LSR's Router ID
Unchanged from the definition in [RFC3477]. Unchanged from the definition in [RFC3477].
Interface ID Interface ID
Unchanged from the definition in [RFC3477]. Unchanged from the definition in [RFC3477].
Actions Actions
This field specifies how the LSP that is being set up is to be This field specifies how the LSP that is being set up is to be
treated. treated.
The field has meaning only on a Path message. On a Resv message The field has meaning only on a Path message. On a Resv
the field SHOULD be set to reflect the value received on the message, the field SHOULD be set to reflect the value received
corresponding Path message, and MUST be ignored on receipt. on the corresponding Path message, and it MUST be ignored on
receipt.
The field is composed of bit flags as follows: The field is composed of bit flags as follows:
-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-
| | | |H|B|R|T|P| | | | |H|B|R|T|P|
-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-
P-flag (Private) P-flag (Private)
0 means that the LSP is to be advertised as a link according 0 means that the LSP is to be advertised as a link according
to the settings of the other flags. to the settings of the other flags.
1 means the LSP is to form a private link and is not to be 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 advertised in the IGP, but is to be used according to the
settings of the other flags. settings of the other flags.
T-flag (TE link) T-flag (TE link)
0 means that the LSP is to be used as a 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 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 still be used as an IP link providing a routing adjacency
defined by the R-flag. as defined by the R-flag.
R-flag (routing adjacency) R-flag (Routing adjacency)
0 means that the link is not to be used as a routing 0 means that the link is not to be used as a routing
adjacency. adjacency.
1 means that the link is to be used to form a routing 1 means that the link is to be used to form a routing
adjacency. adjacency.
B-flag (bundle) B-flag (Bundle)
0 means that the LSP will not form part of a link 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 1 means that the LSP will form part of a bundle. See Section
3.3 for more details. 3.3 for more details.
H-flag (hierarchy/stitching) H-flag (Hierarchy/stitching)
The use of an LSP as an H-LSP or as an S-LSP is usually 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 implicit from the network technologies of the networks and
LSP, but this is not always the case (for example, in PSC the LSP, but this is not always the case (for example, in PSC
networks). networks).
0 means LSP to be used as a hierarchical LSP. 0 means that the LSP is to be used as a hierarchical LSP.
1 means LSP to be used as a stitching segment. 1 means that the LSP is to be used as a stitching segment.
Other bits are reserved for future use. They MUST be set to zero Other bits are reserved for future use. They MUST be set to
on transmission and SHOULD be ignored on receipt. zero on transmission and SHOULD be ignored on receipt.
Note that all defined bit flags have meaning at the same time. 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 An LSP that is to form an FA would carry the Actions field set
to 0x00. That is: to 0x00. That is:
P=0 (advertised) P=0 (advertised)
T=0 (TE link) T=0 (TE link)
R=0 (not a routing adjacency) R=0 (not a routing adjacency)
B=0 (not a bundle) B=0 (not a bundle)
H=0 (hierarchical LSP) H=0 (hierarchical LSP)
Reserved Reserved
The Reserved bits MUST be set to zero on transmission and SHOULD The Reserved bits MUST be set to zero on transmission and
be ignored on receipt. SHOULD be ignored on receipt.
TLVs TLVs
Zero, one, or more TLVs may be present. Each TLV is encoded as Zero, one, or more TLVs may be present. Each TLV is encoded as
follows: follows:
Type (16 bits) Type (16 bits)
The identifier of the TLV. Two type values are defined in The identifier of the TLV. Two type values are defined in
this document: this document:
1 IGP Instance Identifier TLV 1 IGP Instance Identifier TLV
2 Component Link Identifier TLV 2 Unnumbered Component Link Identifier TLV
3 IPv4 Numbered Component Link Identifier TLV
4 IPv6 Numbered Component Link Identifier TLV
Length (16 bits) Length (16 bits)
Indicates the total length of the TLV in octets. I.e., Indicates the total length of the TLV in octets, i.e., 4 +
4 + the length of the value field in octets. A value field the length of the value field in octets. A value field
whose length is not a multiple of four MUST be zero-padded whose length is not a multiple of four MUST be zero-padded
so that the TLV is four-octet aligned. so that the TLV is four-octet aligned.
Value Value
The data for the TLV padded as described above. The data for the TLV padded as described above.
If this object is carried in a Path message it is known as the 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 "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 message, the object is known as the "Reverse Interface ID" for the
LSP. LSP.
3.1.3. IPv4 Numbered Links with Action Identification 3.1.3. IPv4 Numbered Links with Action Identification
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined
to carry an IPv4 numbered interface address. 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 = 2 (TBD by IANA) C-NUM = 193, C-Type = 2
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 Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Interface Address IPv4 Interface Address
The address assigned to the interface the sender applies to The address assigned to the interface that the sender applies
this LSP. to this LSP.
Actions Actions
See Section 3.1.2. See Section 3.1.2.
Reserved Reserved
See Section 3.1.2. See Section 3.1.2.
TLVs TLVs
See Section 3.1.2. See Section 3.1.2.
If this object is carried in a Path message it is known as the 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 "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 message, the object is known as the "Reverse Interface ID" for the
LSP. LSP.
3.1.4. IPv6 Numbered Links with Action Identification 3.1.4. IPv6 Numbered Links with Action Identification
A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined
to carry an IPv6 numbered interface address. 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 = 3 (TBD by IANA) C-NUM = 193, C-Type = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Interface Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actions | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Interface Address IPv6 Interface Address
The address assigned to the interface the sender applies to The address assigned to the interface the sender applies to
this LSP. this LSP.
Actions Actions
See Section 3.1.2. See Section 3.1.2.
Reserved Reserved
See Section 3.1.2. See Section 3.1.2.
TLVs TLVs
See Section 3.1.2. See Section 3.1.2.
If this object is carried in a Path message it is known as the 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 "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 message, the object is known as the "Reverse Interface ID" for the
LSP. LSP.
3.2. Target IGP Identification TLV 3.2. Target IGP Identification TLV
If the LSP being set up is to be advertised as a link, the egress 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 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 advertisement. The default in [RFC4206] and [RFC3477] is that the
is advertised as an FA, that is, in the same instance of the IGP as LSP is advertised as an FA, that is, in the same instance of the IGP
was used to advertise the TE links that the LSP traverses. as was used to advertise the TE links that the LSP traverses.
In order to facilitate an indication from the ingress to the egress In order to facilitate an indication from the ingress to the egress
of which IGP instance to use, the IGP Identification TLV is defined of which IGP instance to use, the IGP Identification TLV is defined
for inclusion in the new variants of the LSP_TUNNEL_INTERFACE_ID for inclusion in the new variants of the LSP_TUNNEL_INTERFACE_ID
object defined in this document. object defined in this document.
The TLV has meaning only in a Path message. It SHOULD NOT be included The TLV has meaning only in a Path message. It SHOULD NOT be
in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and MUST be included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and
ignored if found. MUST be ignored if found.
If the P-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID 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 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 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 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 the TE links that the LSP traverses. Thus, for an FA, the TLV can be
omitted; alternatively, the IGP Instance TLV may be present omitted; alternatively, the IGP Instance TLV may be present and
identifying the IGP instance or carrying the reserved value identify the IGP instance or carry the reserved value 0xffffffff.
0xffffffff.
If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID 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 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 is not to be advertised as a link, this TLV SHOULD NOT be present and
MUST be ignored if encountered. MUST be ignored if encountered.
The TLV is formatted as described in Section 3.1.2. The Type field 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: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGP Instance Identifier | | IGP Instance Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IGP Instance Identifier IGP Instance Identifier
A 32-bit identifier be assigned to each of the IGP instances A 32-bit identifier assigned to each of the IGP instances within a
within a network, such that ingress and egress LSRs have the same network, such that ingress and egress LSRs have the same
understanding of these numbers. This is a management understanding of these numbers. This is a management
configuration exercise outside the scope of this document. configuration exercise outside the scope of this document.
Note that the IGP Instance Identifier might be mapped from an Note that the IGP Instance Identifier might be mapped from an
instance identifier used in the IGP itself (such as section 2.4 instance identifier used in the IGP itself (such as section 2.4 of
of [RFC5340] for OSPFv3, or [OSPFv2-MI] for OSPFv2) as a matter [RFC5340] for OSPFv3, or [OSPFv2-MI] for OSPFv2) as a matter of
of network policy. See [OSPF-TI] for further discussion of this network policy. See [OSPF-TI] for further discussion of this
topic in OSPF, and [ISIS-GENAP] for IS-IS. topic in OSPF, and [ISIS-GENAP] for IS-IS.
The value 0xffffffff is reserved to mean that the LSP is to be 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 advertised in the same instance of the IGP as was used to
advertise the TE links that the LSP traverses. advertise the TE links that the LSP traverses.
3.3. Component Link Identification TLV 3.3. Component Link Identification TLV
If the LSP that is being set up is to be used as a component link in 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 a link bundle [RFC4201], it is necessary to indicate both the
identity of the component link and the identity of the link bundle. identity of the component link and the identity of the link bundle.
Furthermore, it is necessary to indicate how the link bundle (that Furthermore, it is necessary to indicate how the link bundle (that
may be automatically created by the establishment of this LSP) is may be automatically created by the establishment of this LSP) is to
to be used and advertised. be used and advertised.
If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID 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 object is set, the other fields of the object apply to the link
bundle itself. That is, the interface identifiers (numbered or bundle itself. That is, the interface identifiers (numbered or
unnumbered) and the other flags in the Actions field apply to the 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. link bundle and not to the component link that the LSP will form.
Furthermore, the IGP Instance Identifier TLV (if present) also Furthermore, the IGP Instance Identifier TLV (if present) also
applies to the link bundle and not to the component link. applies to the link bundle and not to the component link.
In order to exchange the identity of the component link, the In order to exchange the identity of the component link, the
Component Link Identifier TLVs are introduced as set out in the Component Link Identifier TLVs are introduced as set out in the next
next sections. If the B-flag is set in the Actions field of the 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 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 these TLVs MUST be present in the LSP_TUNNEL_INTERFACE_ID object in
both the Path and Resv objects. both the Path and Resv objects.
3.3.1. Unnumbered Component Link Identification 3.3.1. Unnumbered Component Link Identification
If the component link is to be unnumbered, the Unnumbered Component If the component link is to be unnumbered, the Unnumbered Component
Link Identifier TLV is used. The TLV is formatted as described in 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 Section 3.1.2. The Type field has the value 2, and the Value field
has the following content: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component Link Identifier | | Component Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Component Link Identifier Component Link Identifier
Unnumbered identifier that is assigned to this component link Unnumbered identifier that is assigned to this component link
within the bundle [RFC4201]. within the bundle [RFC4201].
3.3.2. IPv4 Numbered Component Link Identification 3.3.2. IPv4 Numbered Component Link Identification
If the component link is identified with an IPv4 address, the IPv4 If the component link is identified with an IPv4 address, the IPv4
Numbered Component Link Identifier TLV is used. The TLV is formatted 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 as described in Section 3.1.2. The Type field has the value 3, and
the Value field has the following content: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address | | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address IPv4 Address
The IPv4 address that is assigned to this component link within The IPv4 address that is assigned to this component link within
the bundle. the bundle.
3.3.3. IPv6 Numbered Component Link Identification 3.3.3. IPv6 Numbered Component Link Identification
If the component link is identified with an IPv6 address, the IPv6 If the component link is identified with an IPv6 address, the IPv6
Numbered Component Link Identifier TLV is used. The TLV is formatted 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 as described in Section 3.1.2. The Type field has the value 4, and
the Value field has the following content: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address | | IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) | | IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) | | IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (continued) | | IPv6 Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address IPv6 Address
The IPv6 address that is assigned to this component link within The IPv6 address that is assigned to this component link within
the bundle. the bundle.
3.4. Link State Advertisement 3.4. Link State Advertisement
The ingress and egress of an LSP that is set up using the The ingress and egress of an LSP that is set up using the
LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP as agreed in LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP as agreed in
the parameters of the object. the parameters of the object.
Where a TE link is created from the LSP, the TE link SHOULD inherit Where a TE link is created from the LSP, the TE link SHOULD inherit
the TE properties of the LSP as described in [RFC5212] but this the TE properties of the LSP as described in [RFC5212], but this
process is subject to local and network-wide policy. process is subject to local and network-wide policy.
It is possible that an LSP will be used to offer capacity and It is possible that an LSP will be used to offer capacity and
connectivity to multiple other networks. In this case, multiple connectivity to multiple other networks. In this case, multiple
instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in the
the same Path and Resv messages. Each instance MUST have a different same Path and Resv messages. Each instance MUST have a different IGP
IGP Instance Identifier. Instance Identifier.
Note, however, that a Path or Resv message MUST NOT contain more than 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 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 if such an object is present, all other instances of the
LSP_TUNNEL_INTERFACE_ID object MUST include an IGP Instance LSP_TUNNEL_INTERFACE_ID object MUST include an IGP Instance
Identifier TLV with IGP Instance Identifier set to a value that Identifier TLV with IGP Instance Identifier set to a value that
identifies some other IGP instance (in particular, not the value identifies some other IGP instance (in particular, not the value
0xffffffff). 0xffffffff).
If the link created from an LSP is advertised in the same IGP 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 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 traverses, the addresses for the new link and for the links from
is built from MUST come from the same address space. which it is built MUST come from the same address space.
If the link is advertised into another IGP instance the addresses If the link is advertised into another IGP instance, the addresses
MAY be drawn from overlapping address spaces such that some addresses MAY be drawn from overlapping address spaces such that some addresses
have different meanings in each IGP instance. 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 signaled in the Tunnel Sender Address in the Sender Template object signaled in the
Path message. It is assumed that the ingress LSR knows the TE Router Path message. It is assumed that the ingress LSR knows the TE Router
ID of the egress LSR since it has chosen to establish an LSP to that ID of the egress LSR since it has chosen to establish an LSP to that
LSR 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 The link interface addresses or link interface identifiers for the
forward and reverse direction links are taken from the forward and reverse direction links are taken from the
LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages LSP_TUNNEL_INTERFACE_ID object on the Path and Resv messages,
respectively. respectively.
When an LSP is torn down through explicit action (a PathTear message When an LSP is torn down through explicit action (a PathTear message
or a PathErr message with the Path_State_Removed flag set) the or a PathErr message with the Path_State_Removed flag set), the
ingress and egress LSRs SHOULD withdraw the advertisement of any link ingress and egress LSRs SHOULD withdraw the advertisement of any link
that the LSP created and that was previously advertised. The link that the LSP created and that was previously advertised. The link
state advertisement MAY be retained as a virtual link in another state advertisement MAY be retained as a virtual link in another
layer network according to network-wide policy [PCE-LAYER]. layer network according to network-wide policy [PCE-LAYER].
3.5. Message Formats 3.5. Message Formats
[RFC3477] does not state where in the Path message or Resv message [RFC3477] does not state where in the Path message or Resv message
the LSP_TUNNEL_INTERFACE_ID object should be placed. the LSP_TUNNEL_INTERFACE_ID object should be placed.
It is RECOMMENDED that new implementations place the It is RECOMMENDED that new implementations place the
LSP_TUNNEL_INTERFACE_ID objects in the Path message immediately after LSP_TUNNEL_INTERFACE_ID objects in the Path message immediately after
the SENDER_TSPEC object, and in the Resv message immediately after the SENDER_TSPEC object, and in the Resv message immediately after
the FILTER_SPEC object. the FILTER_SPEC object.
All implementations SHOULD be able to handle received messages with All implementations SHOULD be able to handle received messages with
objects in any order as described in [RFC3209]. objects in any order, as described in [RFC3209].
3.6. Error Cases and Non-Acceptance 3.6. Error Cases and Non-Acceptance
Error cases and non-acceptance of new object variants caused by back- Error cases and non-acceptance of new object variants caused by back-
level implementations are discussed in Section 3.7. level implementations are discussed in Section 3.7.
An egress LSR that receives an LSP_TUNNEL_INTERFACE_ID object may An egress LSR that receives an LSP_TUNNEL_INTERFACE_ID object may
have cause to reject the parameters carried in the object for a 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 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 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, the list below. In most cases, the error will arise during LSP
no Resv state will exist, and the PathErr will cause Path state to be setup, no Resv state will exist, and the PathErr will cause Path
removed. Where the error arises after the LSP has been successfully state to be removed. Where the error arises after the LSP has been
set up, the PathErr SHOULD be sent with the Path_State_Removed flag successfully set up, the PathErr SHOULD be sent with the
[RFC3473] clear so that the LSP remains operational. Path_State_Removed flag [RFC3473] clear so that the LSP remains
operational.
The error cases identified are as follows and are reported using the 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 new error code 'LSP Hierarchy Issue' (code 38) and the error values
error values listed below. listed below.
Error | Error | Error-case Error | Error | Error-case
code | value | code | value |
------+-------+------------------------------------------------------ ------+-------+------------------------------------------------------
34 1 Link advertisement not supported 38 1 Link advertisement not supported
34 2 Link advertisement not allowed by policy 38 2 Link advertisement not allowed by policy
34 3 TE link creation not supported 38 3 TE link creation not supported
34 4 TE link creation not allowed by policy 38 4 TE link creation not allowed by policy
34 5 Routing adjacency creation not supported 38 5 Routing adjacency creation not supported
34 6 Routing adjacency creation not allowed by policy 38 6 Routing adjacency creation not allowed by policy
34 7 Bundle creation not supported 38 7 Bundle creation not supported
34 8 Bundle creation not allowed by policy 38 8 Bundle creation not allowed by policy
34 9 Hierarchical LSP not supported 38 9 Hierarchical LSP not supported
34 10 LSP stitching not supported 38 10 LSP stitching not supported
34 11 Link address type or family not supported 38 11 Link address type or family not supported
34 12 IGP instance unknown 38 12 IGP instance unknown
34 13 IGP instance advertisement not allowed by policy 38 13 IGP instance advertisement not allowed by policy
34 14 Component link identifier not valid 38 14 Component link identifier not valid
34 15 Unsupported component link identifier address family 38 15 Unsupported component link identifier address family
When an ingress LSR receives an LSP_TUNNEL_INTERFACE_ID object on a 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 Resv message, it may need to reject it because of the setting of
certain parameters in the object. Since these reasons all represent certain parameters in the object. Since these reasons all represent
errors rather than negotiable parameter-mismatches, the ingress errors rather than mismatches of negotiable parameters, the ingress
SHOULD respond with a PathTear to remove the LSP. The ingress MAY use SHOULD respond with a PathTear to remove the LSP. The ingress MAY
a ResvErr with one of the following error codes, allowing the egress use a ResvErr with one of the following error codes, allowing the
the option to correct the error in a new Resv message, or to tear the egress the option to correct the error in a new Resv message, or to
LSP with a PathErr with Path_State_Removed flag set. An ingress that tear down the LSP with a PathErr with the Path_State_Removed flag
uses the ResvErr MUST take precautions against a protocol loop where set. An ingress that uses the ResvErr MUST take precautions against
the egress responds with the same LSP_TUNNEL_INTERFACE_ID object with a protocol loop where the egress responds with the same
the same or different) issues. LSP_TUNNEL_INTERFACE_ID object with the same (or different) issues.
Error | Error | Error-case Error | Error | Error-case
code | value | code | value |
------+-------+------------------------------------------------------ ------+-------+------------------------------------------------------
34 11 Link address type or family not supported 38 11 Link address type or family not supported
34 14 Component link identifier not valid 38 14 Component link identifier not valid
34 15 Unsupported component link identifier address family 38 15 Unsupported component link identifier address family
34 16 Component link identifier missing 38 16 Component link identifier missing
3.7. Backward Compatibility 3.7. Backward Compatibility
The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class
number of 193. According to [RFC2205], this means that a node that number of 193. According to [RFC2205], this means that a node that
does not understand the object SHOULD ignore the object but forward does not understand the object SHOULD ignore the object but forward
it, unexamined and unmodified. Thus there are no issues with transit it, unexamined and unmodified. Thus, there are no issues with
LSRs supporting the pre-existing or new Class Types of this object. transit LSRs supporting the pre-existing or new Class Types of this
object.
A back-level ingress node will behave as follows: A back-level ingress node will behave as follows:
- It will not issue Path messages containing LSP_TUNNEL_INTERFACE_ID - It will not issue Path messages containing LSP_TUNNEL_INTERFACE_ID
objects with the new Class Types defined in this document. objects with the new Class Types defined in this document.
- It will reject Resv messages containing LSP_TUNNEL_INTERFACE_ID - It will reject Resv messages containing LSP_TUNNEL_INTERFACE_ID
objects with the new Class Types defined in this document as objects with the new Class Types defined in this document as
described in [RFC2205]. In any case, such a situation would described in [RFC2205]. In any case, such a situation would
represent an error by the egress. represent an error by the egress.
- It will continue to use the LSP_TUNNEL_INTERFACE_ID object with - It will continue to use the LSP_TUNNEL_INTERFACE_ID object with
Class Type 1 as defined in [RFC3477]. This behavior is supported by Class Type 1 as defined in [RFC3477]. This behavior is supported
back-level egresses and by egresses conforming to this document. by back-level egresses and by egresses conforming to this document.
- According to an informal survey, there is no significant deployment - According to an informal survey, there is no significant deployment
of numbered FA establishment following the procedures defined in of numbered FA establishment following the procedures defined in
[RFC4206] and set out in Section 1.3.6 of this document. It is [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 therefore safe to assume that back-level ingress LSRs will not use
this mechanism. this mechanism.
A back-level egress node will behave as follows: A back-level egress node will behave as follows:
- It will continue to support the LSP_TUNNEL_INTERFACE_ID object with - It will continue to support the LSP_TUNNEL_INTERFACE_ID object with
Class Type 1 as defined in [RFC3477] if issued by an ingress. Class Type 1, as defined in [RFC3477], if issued by an ingress.
- It will reject a Path message that carries an - It will reject a Path message that carries an
LSP_TUNNEL_INTERFACE_ID object with any of the new Class Types LSP_TUNNEL_INTERFACE_ID object with any of the new Class Types
defined in this document using the procedures of [RFC2205]. This defined in this document using the procedures of [RFC2205]. This
will inform the ingress that the egress is a back-level LSR. will inform the ingress that the egress is a back-level LSR.
- It will not expect to use the procedures for numbered FA - It will not expect to use the procedures for numbered FA
establishment defined in [RFC4206] and set out in Section 1.3.6 of establishment defined in [RFC4206] and set out in Section 1.3.6 of
this document. this document.
In summary, the new mechanisms defined in this document do not impact In summary, the new mechanisms defined in this document do not impact
the method to exchange unnumbered FA information described in the method to exchange unnumbered FA information described in
[RFC3477]. That mechanism can be safely used in combination with the [RFC3477]. That mechanism can be safely used in combination with the
new mechanisms described here and is functionally equivalent to using new mechanisms described here and is functionally equivalent to using
the new C-Type indicating an unnumbered link with target IGP instance the new C-Type indicating an unnumbered link with target IGP instance
identifier with the Target IGP Instance value set to 0xffffffff. identifier with the Target IGP Instance value set to 0xffffffff.
The mechanisms in this document obsolete the method to exchange the The mechanisms in this document obsolete the method to exchange the
numbered FA information described in [RFC4206] as described in numbered FA information described in [RFC4206] as described in
Section 1.4.6. Section 1.4.6.
4. Security Considerations 4. Security Considerations
[RFC3477] points out that one can argue that the use of the extra [RFC3477] points out that one can argue that the use of the extra
interface identifier that it provides could make an RSVP message interface identifier that it provides could make an RSVP message
harder to spoof. In that respect, the minor extensions to the harder to spoof. In that respect, the minor extensions to the
protocol made in this document do not constitute an additional protocol made in this document do not constitute an additional
security risk, but could also be said to improve security. security risk, but could also be said to improve security.
It should be noted that the ability of an ingress LSR to request that It should be noted that the ability of an ingress LSR to request that
an egress LSR advertise an LSP as a TE link MUST be subject to an egress LSR advertise an LSP as a TE link MUST be subject to
appropriate policy checks at the egress LSR. That is, the egress LSR appropriate policy checks at the egress LSR. That is, the egress LSR
MUST NOT automatically accept the word of the ingress unless it is MUST NOT automatically accept the word of the ingress unless it is
configured with such a policy. configured with such a policy.
Further details of security for MPLS-TE and GMPLS can be found in Further details of security for MPLS-TE and GMPLS can be found in
[GMPLS-SEC]. [RFC5920].
5. IANA Considerations 5. IANA Considerations
5.1. New Class Types 5.1. New Class Types
IANA maintains a registry of RSVP parameters called "Resource IANA maintains a registry of RSVP parameters called "Resource
Reservation Protocol (RSVP) Parameters" with a sub-registry called Reservation Protocol (RSVP) Parameters" with a sub-registry called
"Class Names, Class Numbers, and Class Types." There is an entry in "Class Names, Class Numbers, and Class Types". There is an entry in
this registry for the LSP_TUNNEL_INTERFACE_ID object defined in this registry for the LSP_TUNNEL_INTERFACE_ID object defined in
[RFC3477] with one Class Type defined. [RFC3477] with one Class Type defined.
IANA is requested to allocate three new Class Types for this object IANA has allocated three new Class Types for this object as defined
as defined in Sections 3.1.2, 3.1.3, and 3.1.4 as follows: in Sections 3.1.2, 3.1.3, and 3.1.4 as follows:
C-Type Meaning Reference C-Type Meaning Reference
--------------------------------------------------------------- ---------------------------------------------------------------
2 IPv4 interface identifier with target [This.doc] 2 IPv4 interface identifier with target [RFC6107]
3 IPv6 interface identifier with target [This.doc] 3 IPv6 interface identifier with target [RFC6107]
4 Unnumbered interface with target [This.doc] 4 Unnumbered interface with target [RFC6107]
5.2. Hierarchy Actions 5.2. Hierarchy Actions
Section 3.1.2 defines an 8-bit flags field in the Section 3.1.2 defines an 8-bit flags field in the
LSP_TUNNEL_INTERFACE_ID object. IANA is requested to create a new LSP_TUNNEL_INTERFACE_ID object. IANA has created a new sub-registry
sub-registry of the "Generalized Multi-Protocol Label Switching of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
(GMPLS) Signaling Parameters" registry called the "Hierarchy Actions" Parameters" registry called the "Hierarchy Actions" sub-registry as
sub-registry as follows: follows:
Registry Name: Hierarchy Actions Registry Name: Hierarchy Actions
Reference: [This.doc] Reference: [RFC6107]
Registration Procedures: IETF Standards Action RFC Registration Procedures: Standards Action
Registry: Registry:
Bit Number Hex Value Name Reference Bit Number Hex Value Name Reference
---------- ----------- ----------------------- --------- ---------- ----------- ----------------------- ---------
0-2 Unassigned 0-2 Unassigned
3 0x10 Hierarchy/stitching (H) [This.doc] 3 0x10 Hierarchy/stitching (H) [RFC6107]
4 0x08 Bundle (B) [This.doc] 4 0x08 Bundle (B) [RFC6107]
5 0x04 Routing adjacency(R) [This.doc] 5 0x04 Routing adjacency (R) [RFC6107]
6 0x02 TE link (T) [This.doc] 6 0x02 TE link (T) [RFC6107]
7 0x01 Private (P) [This.doc] 7 0x01 Private (P) [RFC6107]
5.3. New Error Codes and Error Values 5.3. New Error Codes and Error Values
IANA maintains a registry of RSVP error codes and error values as the IANA maintains a registry of RSVP error codes and error values as the
"Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry
of the "Resource Reservation Protocol (RSVP) Parameters" registry. of the "Resource Reservation Protocol (RSVP) Parameters" registry.
IANA is requested to define a new error code with suggested value 34 IANA has defined a new error code with value 38 as below (see also
as below (see also Section 3.6). Section 3.6).
Error Code Meaning Error Code Meaning
34 LSP Hierarchy Issue [This.doc] 38 LSP Hierarchy Issue [RFC6107]
IANA is requested to list the following error values for this error IANA has listed the following error values for this error code (see
code (see also Section 3.6). also Section 3.6).
This Error Code has the following globally-defined Error This Error Code has the following globally-defined Error
Value sub-codes: Value sub-codes:
1 = Link advertisement not supported [This.doc] 1 = Link advertisement not supported [RFC6107]
2 = Link advertisement not allowed by policy [This.doc] 2 = Link advertisement not allowed by policy [RFC6107]
3 = TE link creation not supported [This.doc] 3 = TE link creation not supported [RFC6107]
4 = TE link creation not allowed by policy [This.doc] 4 = TE link creation not allowed by policy [RFC6107]
5 = Routing adjacency creation not supported [This.doc] 5 = Routing adjacency creation not supported [RFC6107]
6 = Routing adjacency creation not allowed by policy [This.doc] 6 = Routing adjacency creation not allowed by policy [RFC6107]
7 = Bundle creation not supported [This.doc] 7 = Bundle creation not supported [RFC6107]
8 = Bundle creation not allowed by policy [This.doc] 8 = Bundle creation not allowed by policy [RFC6107]
9 = Hierarchical LSP not supported [This.doc] 9 = Hierarchical LSP not supported [RFC6107]
10 = LSP stitching not supported [This.doc] 10 = LSP stitching not supported [RFC6107]
11 = Link address type or family not supported [This.doc] 11 = Link address type or family not supported [RFC6107]
12 = IGP instance unknown [This.doc] 12 = IGP instance unknown [RFC6107]
13 = IGP instance advertisement not allowed by policy [This.doc] 13 = IGP instance advertisement not allowed by policy [RFC6107]
14 = Component link identifier not valid [This.doc] 14 = Component link identifier not valid [RFC6107]
15 = Unsupported component link identifier address [This.doc] 15 = Unsupported component link identifier address [RFC6107]
family family
16 = Component link identifier missing [This.doc] 16 = Component link identifier missing [RFC6107]
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Lou Berger, Deborah Brungard, John The authors would like to thank Lou Berger, Deborah Brungard, John
Drake, Yakov Rekhter, Igor Bryskin, and Lucy Yong for their valuable Drake, Yakov Rekhter, Igor Bryskin, and Lucy Yong for their valuable
discussions and comments. discussions and comments.
7. References 7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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 7.1. Normative References
Label Switching Architecture", RFC 3031, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Requirement Levels", BCP 14, RFC 2119, March 1997.
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
Switching (MPLS) Signaling Resource ReserVation Protocol and S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Version 1 Functional Specification", RFC 2205,
January 2003. September 1997.
[RFC3477] Kompella, K. and Rekhter, Y., "Signalling Unnumbered Links [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
in Resource ReSerVation Protocol - Traffic Engineering "Multiprotocol Label Switching Architecture", RFC
(RSVP-TE)", RFC 3477, January 2003. 3031, January 2001.
[RFC4201] Kompella, K., Rekhter, Y., and Berger, L.," Link Bundling [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Generalized MPLS TE", RFC 4206, October 2005. Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC5150] Ayyangar, A., Vasseur, J.P, and Farrel, A., "Label Switched [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Path Stitching with Generalized Multiprotocol Label Links in Resource ReSerVation Protocol - Traffic
Switching Traffic Engineering (GMPLS TE)", RFC 5150, Engineering (RSVP-TE)", RFC 3477, January 2003.
February 2008.
7.2. Informative References [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link
Bundling in MPLS Traffic Engineering (TE)", RFC 4201,
October 2005.
[RFC1195] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
dual environments", RFC 1195, December 1990 (LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A.
September 1991. Farrel, "Label Switched Path Stitching with
Generalized Multiprotocol Label Switching Traffic
Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 7.2. Informative References
[RFC3630] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP
(TE) Extensions to OSPF Version 2", RFC 3630, September and dual environments", RFC 1195, December 1990.
2003.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions [RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages",
in Support of Generalized Multi-Protocol Label Switching RFC 1256, September 1991.
(GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K. Ed. and Y. Rekhter, Ed., "OSPF Extensions in [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
Support of Generalized Multi-Protocol Label Switching 1998.
(GMPLS)", RFC 4203, October 2005.
[RFC5212] Shiomoto, K., et al, "Requirements for GMPLS-Based Multi- [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July Engineering (TE) Extensions to OSPF Version 2", RFC
2008 3630, September 2003.
[RFC5305] Smit, H. and T. Li, "Intermediate System to Intermediate [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
System (IS-IS) Extensions for Traffic Engineering (TE)", Extensions in Support of Generalized Multi-Protocol
RFC 5305, October 2008. Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC5307] Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate System [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
to Intermediate System (IS-IS) Extensions in Support of Extensions in Support of Generalized Multi-Protocol
Generalized Multi-Protocol Label Switching (GMPLS)", RFC Label Switching (GMPLS)", RFC 4203, October 2005.
5307, October 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL.,
2008. Vigoureux, M., and D. Brungard, "Requirements for
GMPLS-Based Multi-Region and Multi-Layer Networks
(MRN/MLN)", RFC 5212, July 2008.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and Lindem, A., [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
(Ed.), "Traffic Engineering Extensions to OSPF version 3", Engineering", RFC 5305, October 2008.
RFC 5329, September 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
IPv6", RFC 5340, July 2008. Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 5307, October 2008.
[GMPLS-SEC] Fang, L., et al., "Security Framework for MPLS and GMPLS [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
Networks", draft-ietf-mpls-mpls-and-gmpls-security- October 2008.
framework, work in progress.
[ISIS-GENAP] Ginsberg, L., Previdi, S., and Shand, M., "Advertising [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem,
Generic Information in IS-IS", draft-ietf-isis-genapp, work Ed., "Traffic Engineering Extensions to OSPF Version
in progress. 3", RFC 5329, September 2008.
[ISIS-IPV6-TE] Harrison, J., Berger, J., and Bartlett, M., "IPv6 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem,
Traffic Engineering in IS-IS", draft-ietf-isis-ipv6-te, "OSPF for IPv6", RFC 5340, July 2008.
work in progress.
[OSPF-TI] Lindem, A., Roy, A., and Mirtorabi, S., "OSPF Transport [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Instance Extensions", draft-ietf-ospf-transport-instance, Networks", RFC 5920, July 2010.
work in progress.
[OSPFv2-MI] Lindem, A., Roy, A., and Mirtorabi, S., "OSPF Multi- [ISIS-GENAP] Ginsberg, L., Previdi, S., and M. Shand, "Advertising
Instance Extensions", draft-ietf-ospf-multi-instance, work Generic Information in IS-IS", Work in Progress,
in progress. November 2010.
[PCE-LAYER] Oki, E. (Ed.), "PCC-PCE Communication and PCE Discovery [ISIS-IPV6-TE] Harrison, J., Berger, J., and M. Bartlett, "IPv6
Requirements for Inter-Layer Traffic Engineering", Traffic Engineering in IS-IS", Work in Progress,
draft-ietf-pce-inter-layer-req, work in progress. September 2010.
8. Editors' Addresses [OSPF-TI] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Transport
Instance Extensions", Work in Progress, October 2010.
Kohei Shiomoto [OSPFv2-MI] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Multi-
NTT Network Service Systems Laboratories Instance Extensions", Work in Progress, October 2010.
3-9-11 Midori
Musashino, Tokyo 180-8585
Japan
Phone: +81 422 59 4402
Email: shiomoto.kohei@lab.ntt.co.jp
Adrian Farrel [PCE-LAYER] Takeda, T., Ed., and A. Farrel, "PCC-PCE Communication
Old Dog Consulting and PCE Discovery Requirements for Inter-Layer Traffic
EMail: adrian@olddog.co.uk Engineering", Work in Progress, December 2010.
9. Authors' Addresses Authors' Addresses
Richard Rabbat Richard Rabbat
Google Inc. Google Inc.
1600 Amphitheatre Pkwy 1600 Amphitheatre Pkwy
Mountain View, CA 94043 Mountain View, CA 94043
Email: rabbat@alum.mit.edu United States of America
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
Email: arthi@juniper.net EMail: arthi@juniper.net
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
Editors' Addresses
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori
Musashino, Tokyo 180-8585
Japan
Phone: +81 422 59 4402
EMail: shiomoto.kohei@lab.ntt.co.jp
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
 End of changes. 259 change blocks. 
642 lines changed or deleted 624 lines changed or added

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