draft-ietf-mpls-lsp-hierarchy-00.txt   draft-ietf-mpls-lsp-hierarchy-01.txt 
Network Working Group Kireeti Kompella Network Working Group Kireeti Kompella
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: January 2001 Yakov Rekhter Expiration Date: March 2001 Yakov Rekhter
Cisco Systems Cisco Systems
LSP Hierarchy with MPLS TE LSP Hierarchy with MPLS TE
draft-ietf-mpls-lsp-hierarchy-00.txt draft-ietf-mpls-lsp-hierarchy-01.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 43 skipping to change at page 2, line 43
In this document we define mechanisms/procedures to accomplish the In this document we define mechanisms/procedures to accomplish the
above. These mechanisms/procedures cover both the routing above. These mechanisms/procedures cover both the routing
(ISIS/OSPF) and the signalling (RSVP/CR-LDP) aspects. (ISIS/OSPF) and the signalling (RSVP/CR-LDP) aspects.
4. Routing aspects 4. Routing aspects
In this section we describe procedures for constructing forwarding In this section we describe procedures for constructing forwarding
adjacencies out of LSPs, and handling of forwarding adjacencies by adjacencies out of LSPs, and handling of forwarding adjacencies by
ISIS/OSPF. Specifically, this section describes how to construct the ISIS/OSPF. Specifically, this section describes how to construct the
information needed to advertise LSPs as links into ISIS/OSPF information needed to advertise LSPs as links into ISIS/OSPF.
Procedures for creation/termination of such LSPs are defined in Procedures for creation/termination of such LSPs are defined in
Section 5. Section 6.
Forwarding adjacencies may be represented as either unnumbered or Forwarding adjacencies may be represented as either unnumbered or
numbered links. In the former case the link IP addresses of numbered links.
forwarding adjacencies are the router IDs on the two ends of the
link. In the latter case the link IP addresses of forwarding
adjacencies could be addresses assigned to some "virtual" interfaces
on a router (it is assumed that a router may have multiple virtual
interfaces).
If there are multiple LSPs that all originate on one LSR and all If there are multiple LSPs that all originate on one LSR and all
terminate on another LSR, then at one end of the spectrum all these terminate on another LSR, then at one end of the spectrum all these
LSPs could be merged (under control of the head-end LSR) into a LSPs could be merged (under control of the head-end LSR) into a
single forwarding adjacency using the concept of Link Bundling (see single forwarding adjacency using the concept of Link Bundling (see
[BUNDLE], while at the other end of the spectrum each such LSP could [BUNDLE], while at the other end of the spectrum each such LSP could
be advertised as its own adjacency. be advertised as its own adjacency.
When a forwarding adjacency is created under administrative control When a forwarding adjacency is created under administrative control
(static provisioning), the attributes of this adjacency have to be (static provisioning), the attributes of this adjacency have to be
provided via configuration. Specifically, the following attributes provided via configuration. Specifically, the following attributes
MAY be configured for the FA-LSP: the head-end address (if left MAY be configured for the FA-LSP: the head-end address (if left
unconfigured, this must default to the head-end LSR's Router ID); the unconfigured, this defaults to the head-end LSR's Router ID); the
tail-end address (this MUST be configured, and must be either the tail-end address (if left unconfigured, the FA will be unnumbered);
Router ID of the tail-end LSR of the forwarding adjacency, or an bandwidth and resource colors constraints. The path taken by the
interface address on the tail-end LSR); bandwidth and resource colors FA-LSP may be either computed by the LSR at the head-end of the FA-
constraints. The path taken by the FA-LSP may be either computed by LSP, or specified by explicit configuration; this choice is
the by the LSR at the head-end of the FA-LSP, or specified by determined by configuration.
explicit configuration; this choice is determined by configuration.
When a forwarding adjacency is created dynamically, its attributes When a forwarding adjacency is created dynamically, its attributes
are inherited from the LSP which induced its creation. Note that the are inherited from the LSP which induced its creation. Note that the
bandwidth of the FA-LSP must be at least as big as the LSP that bandwidth of the FA-LSP must be at least as big as the LSP that
induced it, but may be bigger if only discrete bandwidths are induced it, but may be bigger if only discrete bandwidths are
available for the FA-LSP. In general, for dynamically provisioned available for the FA-LSP. In general, for dynamically provisioned
forwarding adjacencies, a policy-based mechanism may be needed to forwarding adjacencies, a policy-based mechanism may be needed to
associate attributes to forwarding adjacencies. associate attributes to forwarding adjacencies.
This document restricts the holding priority of the FA-LSP to 0,
regardless of how the FA-LSP is created.
4.1. Traffic Engineering parameters 4.1. Traffic Engineering parameters
In this section, the Traffic Engineering parameters (see [OSPF-TE] In this section, the Traffic Engineering parameters (see [OSPF-TE]
and [ISIS-TE]) for forwarding adjacencies are described. and [ISIS-TE]) for forwarding adjacencies are described.
4.1.1. Link type (OSPF only) 4.1.1. Link type (OSPF only)
The Link Type of a forwarding adjacency is set to "point-to-point". The Link Type of a forwarding adjacency is set to "point-to-point".
4.1.2. Link ID (OSPF only) 4.1.2. Link ID (OSPF only)
The Link ID is set to the Router ID of the tail end of FA-LSP. The Link ID is set to the Router ID of the tail end of FA-LSP.
4.1.3. Local and remote interface IP address 4.1.3. Local and remote interface IP address
The local interface IP address (OSPF) or IPv4 interface address If the FA is to be numbered, the local interface IP address (OSPF) or
(ISIS) is set to the head-end address of the FA-LSP. The remote IPv4 interface address (ISIS) is set to the head-end address of the
interface IP address (OSPF) or IPv4 neighbor address (ISIS) is set to FA-LSP. The remote interface IP address (OSPF) or IPv4 neighbor
the tail end address of the FA-LSP. address (ISIS) is set to the tail-end address of the FA-LSP.
If the FA is to be unnumbered, the advertising LSR must assign an
interface identifier to the FA, just like to any other unnumbered
link (see [UNNUM]). The interface identifier MUST be unique within
the scope of the advertising LSR. The local interface IP address
(OSPF) or IPv4 interface address (ISIS) is set to the router ID of
the head end of the FA-LSP. The first two octets of the remote
interface IP address (OSPF) or IPv4 neighbor address (ISIS) are set
to zero; the remaining two octets are set to the assigned interface
identifier.
If an FA-LSP does not have a tail-end address, the advertised FA is
unnumbered. However, one may configure an FA to be unnumbered even
if the corresponding FA-LSP has a tail-end address, for example in
the case that there are multiple FA-LSPs to the same tail-end
address.
4.1.4. Traffic Engineering metric 4.1.4. Traffic Engineering metric
By default the TE metric on the forwarding adjacency is set to max(1, By default the TE metric on the forwarding adjacency is set to max(1,
(the TE metric of the FA-LSP path) - 1) so that it attracts traffic (the TE metric of the FA-LSP path) - 1) so that it attracts traffic
in preference to setting up a new LSP. This may be overridden via in preference to setting up a new LSP. This may be overridden via
configuration at the head-end of the forwarding adjacency. configuration at the head-end of the forwarding adjacency.
4.1.5. Maximum bandwidth 4.1.5. Maximum bandwidth
skipping to change at page 5, line 7 skipping to change at page 5, line 7
of the forwarding adjacency is set to the bandwidth of the FA-LSP. of the forwarding adjacency is set to the bandwidth of the FA-LSP.
4.1.7. Resource class/color 4.1.7. Resource class/color
By default, a forwarding adjacency does not have resource colors By default, a forwarding adjacency does not have resource colors
(administrative groups). This may be overridden by configuration at (administrative groups). This may be overridden by configuration at
the head-end of the forwarding adjacency. the head-end of the forwarding adjacency.
4.1.8. Link Mux Capability 4.1.8. Link Mux Capability
The Link Mux Capability (see Section 4.3.1) associated with the The Link Mux Capability (see Section 7.1) associated with the
forwarding adjacency is the Link Mux Capability of the last link in forwarding adjacency is the Link Mux Capability of the last link in
the FA-LSP. the FA-LSP.
4.1.9. Path information 4.1.9. Path information
A forwarding adjacency advertisement could contain the information A forwarding adjacency advertisement could contain the information
about the path taken by the FA-LSP associated with that forwarding about the path taken by the FA-LSP associated with that forwarding
adjacency. This information may be used for path calculation by adjacency. This information may be used for path calculation by other
other LSRs. This information is carried in the Path sub-TLV, which LSRs. This information is carried in the Path TLV. In both IS-IS and
is a sub-TLV of the Link Mux Capability TLV. In both IS-IS and OSPF, OSPF, this TLV is encoded as follows: the type is TBD, the length is
this sub-TLV is encoded as follows: the type is 1, the length is 4 4 times the path length, and the value is a list of 4 octet IPv4
times the path length, and the value is a list of 4 octet IPv4
addresses identifying the links in the order that they form the path addresses identifying the links in the order that they form the path
of the forwarding adjacency. of the forwarding adjacency.
It is possible that the underlying Path sub-TLV might change over It is possible that the underlying Path information might change over
time, via configuration updates, or dynamic route modifications. If time, via configuration updates, or dynamic route modifications,
forwarding adjacencies are bundled (via link bundling), and if the resulting in the change of the Path TLV.
resulting bundled link carries a Path sub-TLV, it MUST be the case
that the underlying path followed by each of the FA-LSPs that form
the component links is the same.
4.2. Other considerations If forwarding adjacencies are bundled (via link bundling), and if the
resulting bundled link carries a Path TLV, it MUST be the case that
the underlying path followed by each of the FA-LSPs that form the
component links is the same.
5. Other considerations
It is expected that forwarding adjacencies will not be used for It is expected that forwarding adjacencies will not be used for
establishing ISIS/OSPF peering relation between the routers at the establishing ISIS/OSPF peering relation between the routers at the
ends of the adjacency. ends of the adjacency.
It may be desired in some cases that forwarding adjacencies only be It may be desired in some cases that forwarding adjacencies only be
used in Traffic Engineering path computations. In IS-IS, this can be used in Traffic Engineering path computations. In IS-IS, this can be
accomplished by setting the default metric of the extended IS accomplished by setting the default metric of the extended IS
reachability TLV for the FA to the maximum link metric (2^24 - 1). reachability TLV for the FA to the maximum link metric (2^24 - 1).
In OSPF, this can be accomplished by not advertising the link as a In OSPF, this can be accomplished by not advertising the link as a
regular LSA, but only as a TE opaque LSA. regular LSA, but only as a TE opaque LSA.
Since LSPs are in general unidirectional, it follows that forwarding Since LSPs are in general unidirectional, it follows that forwarding
adjacencies are (by definition) unidirectional links. Therefore, the adjacencies are (by definition) unidirectional links. Therefore, the
TE path computation procedures should not perform two-way TE path computation procedures should not perform two-way
connectivity check on the links used by the procedures. connectivity check on the links used by the procedures.
4.3. Controlling FA-LSPs boundaries 6. Controlling FA-LSPs boundaries
To facilitate controlling the boundaries of FA-LSPs this document To facilitate controlling the boundaries of FA-LSPs this document
introduces two new mechanisms: Link Mux Capability, and "LSP region" introduces two new mechanisms: Link Mux Capability, and "LSP region"
(or just "region"). (or just "region").
4.3.1. Link Mux Capability TLV 6.1. Link Mux Capability sub-TLV
Associated with each link (including forwarding adjacencies) is a new Associated with each link (including forwarding adjacencies) is a new
attribute - Link Mux Capability. In this section we define the Link attribute - Link Mux Capability. In this section we define the Link
Mux Capability TLV and describe the various values it can take. Mux Capability sub-TLV and describe the various values it can take.
A network may have links with different multiplexing/demultiplexing A network may have links with different multiplexing/demultiplexing
capabilities. For example, a node may not be able to demultiplex capabilities. For example, a node may not be able to demultiplex
individual packets on a given link, but it may be able to multiplex/ individual packets on a given link, but it may be able to multiplex/
demultiplex channels within a SONET payload. The Link Mux Capability demultiplex channels within a SONET payload. The Link Mux Capability
TLV identifies the associated multiplexing/demultiplexing capability sub-TLV identifies the associated multiplexing/demultiplexing
of a link. At present, the Link Mux Capability TLV has one defined capability of a link. If there is no Link Mux Capability attribute
sub-TLV, the Path TLV, described in section 4.1.9. for a link, the link is assumed to be packet-switch capable (PSC-1).
In ISIS the Link Mux Capability is a sub-TLV of the extended IS In ISIS the Link Mux Capability is a sub-TLV of the extended IS
reachability TLV (type 22) as defined in [ISIS-TE]. The type of the reachability TLV (type 22) as defined in [ISIS-TE]. The type of the
Link Mux Capability TLV is 19. The length of the TLV is one octet Link Mux Capability sub-TLV is 19. The length of the TLV is one
plus the length of sub-TLVs of the Link Mux Capability TLV. The value octet. The value field of the sub-TLV contains the Link Mux
field of the TLV contains the Link Mux Capability, encoded as Capability, encoded as follows:
follows:
Value Link Mux Capabilities Value Link Mux Capabilities
1 Packet-Switch Capable-1 (PSC-1) 1 Packet-Switch Capable-1 (PSC-1)
2 Packet-Switch Capable-2 (PSC-2) 2 Packet-Switch Capable-2 (PSC-2)
3 Packet-Switch Capable-3 (PSC-3) 3 Packet-Switch Capable-3 (PSC-3)
4 Packet-Switch Capable-4 (PSC-4) 4 Packet-Switch Capable-4 (PSC-4)
50 Time-Division-Multiplex Capable (TDM) 51 Layer-2 Switch Capable (L2SC)
100 Lambda-Switch Capable (LSC) 100 Time-Division-Multiplex Capable (TDM)
150 Fiber-Switch Capable (FSC) 150 Lambda-Switch Capable (LSC)
200 Fiber-Switch Capable (FSC)
In the OSPF Traffic Engineering LSA, the Link Mux Capability TLV is a In the OSPF Traffic Engineering LSA, the Link Mux Capability is a
sub-TLV of the Link TLV as defined in [OSPF-TE], with type 11 and sub-TLV of the Link TLV as defined in [OSPF-TE], with type 11 and
length of four octets plus the length of the sub-TLVs of the Link Mux length of four octets. The value field is taken from the above list.
Capability TLV. The value field is taken from the above list. The The format of the Link Mux Capability sub-TLV is as shown in the next
format of the Link Mux Capability sub-TLV is as shown below: figure.
If a link is of type L2SC, that means that the node receiving layer 2
frames over this link can switch the received frames based on the
layer 2 address. For example, a link terminating on an ATM switch
would be considered L2SC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | Length | | 11 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Mux Cap. | Reserved | | Link Mux Cap. | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs (if any) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a link is of type PSC-1 through PSC-4, that means that the node If a link is of type PSC-1 through PSC-4, that means that the node
receiving data over this link can demultiplex (switch) the received receiving data over this link can demultiplex (switch) the received
data on a packet-by-packet basis. The various levels of PSC data on a packet-by-packet basis. The various levels of PSC
establish a hierarchy of LSPs tunneled within LSPs. establish a hierarchy of LSPs tunneled within LSPs.
If a link is of type TDM, that means that the node receiving data If a link is of type TDM, that means that the node receiving data
over this link can multiplex or demultiplex channels within a over this link can multiplex or demultiplex channels within a
SONET/SDH payload. SONET/SDH payload.
If a link is of type LSC, that means that the node receiving data If a link is of type LSC, that means that the node receiving data
over this link can recognize and switch individual lambdas within the over this link can recognize and switch individual lambdas within the
link (fiber). link (fiber).
If a link is of type FSC, that means that the node receiving data If a link is of type FSC, that means that the node receiving data
over this link (fiber) can switch the entire contents to another link over this link (fiber) can switch the entire contents to another link
(fiber) (without distinguishing lambdas, channels or packets). (fiber) (without distinguishing lambdas, channels or packets).
Note that the node that is advertising a given link (i.e., the node Note that the node that is advertising a given link (i.e., the node
that is transmitting) needs to know the multiplex/demultiplex that is transmitting) needs to know the multiplex/demultiplex
capacbilities at the other end of the link (i.e., the receiving end capabilities at the other end of the link (i.e., the receiving end of
of the link). This is accomplished through coordinated configuration the link). One way to accomplish this is through configuration.
between the nodes, at each end of the link. Other options to accomplish this are outside the scope of this
document.
4.3.2. LSP regions 6.2. LSP regions
The information carried in the Link Mux Capabilities is used to The information carried in the Link Mux Capabilities is used to
construct LSP regions, and determine regions' boundaries as follows. construct LSP regions, and determine regions' boundaries as follows.
Define an ordering among link mux capabilities as follows: PSC-1 < Define an ordering among link mux capabilities as follows: PSC-1 <
PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC. Given two links link-1 and PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC. Given two links link-1 and
link-2 with link types lmc-1 and lmc-2 respectively, say that link-1 link-2 with link mux capabilities lmc-1 and lmc-2 respectively, say
< link-2 iff lmc-1 < lmc-2 or lmc-1 == lmc-2 == TDM, and link-1's that link-1 < link-2 iff lmc-1 < lmc-2 or lmc-1 == lmc-2 == TDM, and
bandwidth is less than link-2's switching granularity. link-1's bandwidth is less than link-2's switching granularity.
Furthermore, say that link-1 is compatible with link-2 iff:
lmc-1 equals lmc-2 and neither is of type TDM; OR
lmc-1 equals lmc-2 equals TDM and both links have the same speed;
OR
lmc-1 and lmc-2 are both packet-switch capable.
Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2, Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2,
node-2, ..., link-n, node-n. If link-i < link-(i+1), we say that the node-2, ..., link-n, node-n. If link-i < link-(i+1), we say that the
LSP has crossed a region boundary at node-i; with respect to that LSP LSP has crossed a region boundary at node-i; with respect to that LSP
path, the LSR at node-i is an edge LSR. The 'other edge' of the path, the LSR at node-i is an edge LSR. The 'other edge' of the
region with respect to the LSP path is node-k, where k is the region with respect to the LSP path is node-k, where k is the
smallest number greater than i+1 such that link-k is compatible with smallest number greater than i+1 such that link-k <= link-i.
link-i.
Path computation may take into account region boundaries when Path computation may take into account region boundaries when
computing a path for an LSP. For example, path computation may computing a path for an LSP. For example, path computation may
restrict the path taken by an LSP to only the links whose Link Mux restrict the path taken by an LSP to only the links whose Link Mux
Capability is PSC-1. Capability is PSC-1.
5. Signalling aspects 7. Signalling aspects
In this section we describe procedures that an LSR at the head-end of In this section we describe procedures that an LSR at the head-end of
a forwarding adjacency uses for handling LSP setup originated by a forwarding adjacency uses for handling LSP setup originated by
other LSR. other LSR.
As we mentioned before, establishment/termination of FA-LSPs may As we mentioned before, establishment/termination of FA-LSPs may
triggered either by mechanisms outside of MPLS (e.g., via triggered either by mechanisms outside of MPLS (e.g., via
administrative control), or by mechanisms within MPLS (e.g., as a administrative control), or by mechanisms within MPLS (e.g., as a
result of the LSR at the edge of an aggregate LSP receiving LSP setup result of the LSR at the edge of an aggregate LSP receiving LSP setup
requests originated by some other LSRs beyond LSP aggregate and its requests originated by some other LSRs beyond LSP aggregate and its
edges). Procedures described in Section 5.1 applied to both cases. edges). Procedures described in Section 7.1 applied to both cases.
Procedures described in Section 5.2 apply only to the latter case. Procedures described in Section 7.2 apply only to the latter case.
5.1. Common procedures 7.1. Common procedures
For the purpose of processing the ERO in a Path/Request message of an For the purpose of processing the ERO in a Path/Request message of an
LSP that is to be tunneled over a forwarding adjacency, an LSR at the LSP that is to be tunneled over a forwarding adjacency, an LSR at the
head-end of the FA-LSP views the LSR at the tail of that FA-LSP as head-end of the FA-LSP views the LSR at the tail of that FA-LSP as
adjacent (one IP hop away). adjacent (one IP hop away).
If the LSR at the tail of the FA-LSP is capable of packet switching, If the Link Mux Capability of the FA-LSP is PSC[1-4], the
the Path/Request message for the tunneled LSP can itself be tunneled Path/Request message for the tunneled LSP MUST be tunneled over the
over the FA-LSP. If the encapsulation on the carrier LSP can FA-LSP. If the encapsulation on the carrier LSP can distinguish IP
distinguish IP from MPLS, the Path/Request message is sent as a plain from MPLS, the Path/Request message is sent as a plain IP packet.
IP packet. Otherwise, the Path/Request message is sent with a label Otherwise, the Path/Request message is sent with a label of 0,
of 0, meaning "pop the label and treat as IP". meaning "pop the label and treat as IP".
If the LSR at the tail of the FA-LSP is not capable of packet If the Link Mux Capability of the FA-LSP is not PSC[1-4], the Path
switching, the Path message is unicast over the control plane to the message is unicast over the control plane to the tail of the carrier
tail of the carrier LSP, without the Router Alert option. The whole LSP, without the Router Alert option. The whole Path message,
Path message, including IP header, MUST also be encapsulated in including IP header, MAY also be encapsulated in another IP header
another IP header whose destination IP address matches the tail's IP whose destination IP address matches the tail's IP address.
address.
The Resv/Mapping message back to the head-end of the FA-LSP (PHOP) The Resv/Mapping message back to the head-end of the FA-LSP (PHOP)
cannot be sent over the same FA-LSP as it is unidirectional. The cannot be sent over the same FA-LSP as it is unidirectional. The
Resv/Mapping message can either take any LSP whose end-point is the Resv/Mapping message can either take any packet-switch capable LSP
head-end of the FA- LSP, or be unicast over the control plane to the whose end-point is the head-end of the FA-LSP, or be unicast over the
head-end. RSVP Resv Messages SHOULD be encapsulated in another IP control plane to the head-end. RSVP Resv Messages MAY be
header whose destination IP address matches the head-end's IP encapsulated in another IP header whose destination IP address
address. matches the head-end's IP address.
When an LSP is tunneled through an FA-LSP, the LSR at the head-end of When an LSP is tunneled through an FA-LSP, the LSR at the head-end of
the FA-LSP subtracts the LSP's bandwidth from the unreserved the FA-LSP subtracts the LSP's bandwidth from the unreserved
bandwidth of the forwarding adjacency. In the presence of link bandwidth of the forwarding adjacency.
bundling (when link bundling is applied to forwarding adjacencies),
when an LSP is tunneled through an FA-LSP, the LSR at the head-end of
the FA-LSP also need to adjust Max LSP bandwidth of the forwarding
adjacency.
5.2. Specific procedures In the presence of link bundling (when link bundling is applied to
forwarding adjacencies), when an LSP is tunneled through an FA-LSP,
the LSR at the head-end of the FA-LSP also need to adjust Max LSP
bandwidth of the forwarding adjacency.
7.2. Specific procedures
When an LSR receives a Path/Request message, the LSR determines When an LSR receives a Path/Request message, the LSR determines
whether it is at the edge of a region with respect to the ERO carried whether it is at the edge of a region with respect to the ERO carried
in the message. The LSR does this by looking up the link types of in the message. The LSR does this by looking up the link mux
the previous hop and the next hop in its IGP database, and comparing capabilities of the previous hop and the next hop in its IGP
them using the relation defined in Section 4.3.2. If the LSR is not database, and comparing them using the relation defined in Section
at the edge of a region, the procedures in this section do not apply. 7.2. If the LSR is not at the edge of a region, the procedures in
this section do not apply.
If the LSR is at the edge of a region, it must then determine the If the LSR is at the edge of a region, it must then determine the
other edge of the region with respect to the ERO, again using the IGP other edge of the region with respect to the ERO, again using the IGP
database. The LSR then extracts the strict hop subsequence from database. The LSR then extracts the strict hop subsequence from
itself to the other end of the region. itself to the other end of the region.
The LSR then compares the strict hop subsequence with all existing The LSR then compares the strict hop subsequence with all existing
FA-LSPs originated by the LSR; if a match is found, that FA-LSP has FA-LSPs originated by the LSR; if a match is found, that FA-LSP has
enough unreserved bandwidth for the LSP being signaled, and the L3PID enough unreserved bandwidth for the LSP being signaled, and the L3PID
of the FA-LSP is compatible with the L3PID of the LSP being signaled, of the FA-LSP is compatible with the L3PID of the LSP being signaled,
skipping to change at page 10, line 17 skipping to change at page 10, line 9
After the LSR establishes the new FA-LSP, the LSR announces this LSP After the LSR establishes the new FA-LSP, the LSR announces this LSP
into IS-IS/OSPF as a forwarding adjacency. into IS-IS/OSPF as a forwarding adjacency.
The unreserved bandwidth of the forwarding adjacency is computed by The unreserved bandwidth of the forwarding adjacency is computed by
subtracting the bandwidth of sessions pending the establishment of subtracting the bandwidth of sessions pending the establishment of
the FA-LSP associated from the bandwidth of the FA-LSP. the FA-LSP associated from the bandwidth of the FA-LSP.
An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP
as a matter of policy local to the LSR. It is expected that the FA- as a matter of policy local to the LSR. It is expected that the FA-
LSP would be torn down once there are no more LSPs carried by the FA- LSP would be torn down once there are no more LSPs carried by the
LSP. When the FA-LSP is torn down, the forwarding adjacency FA-LSP. When the FA-LSP is torn down, the forwarding adjacency
associated with the FA-LSP is no longer advertised into IS-IS/OSPF. associated with the FA-LSP is no longer advertised into IS-IS/OSPF.
6. Security Considerations 7.3. FA-LSP Holding Priority
The value of the holding priority of an FA-LSP must be the minimum of
the configured holding priority of the FA-LSP and the holding
priorities of the LSPs tunneling through the FA-LSP (note that
smaller priority values denote higher priority). Thus, if an LSP of
higher priority than the FA-LSP tunnels through the FA-LSP, the FA-
LSP is itself promoted to the higher priority. However, if the
tunneled LSP is torn down, the FA-LSP need not drop its priority to
its old value right away; it may be advisable to apply hysteresis in
this case.
If the holding priority of an FA-LSP is configured, this document
restricts it to 0.
8. Security Considerations
Security issues are not discussed in this document. Security issues are not discussed in this document.
7. Acknowledgements 9. Acknowledgements
Many thanks to Alan Hannan, whose early discussions with Yakov Many thanks to Alan Hannan, whose early discussions with Yakov
Rekhter contributed greatly to the notion of Forwarding Adjacencies. Rekhter contributed greatly to the notion of Forwarding Adjacencies.
We would also like to thank George Swallow, Quaizar Vohra and Ayan We would also like to thank George Swallow, Quaizar Vohra and Ayan
Banerjee. Banerjee.
8. References 10. References
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering", draft-kompella-mpls-bundle-02.txt (work in MPLS Traffic Engineering", draft-kompella-mpls-bundle-02.txt (work in
progress) progress)
[ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-traffic-01.txt (work in progress) Engineering", draft-ietf-isis-traffic-01.txt (work in progress)
[OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to
OSPF", draft-katz-yeung-ospf-traffic-01.txt (work in progress) OSPF", draft-katz-yeung-ospf-traffic-01.txt (work in progress)
9. Author Information [UNNUM] Kompella, K., Rekhter, Y., "Traffic Engineering with
Unnumbered Links", draft-kompella-mpls-unnum-01.txt (work in
progress)
11. Author Information
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
385 Ravendale Drive 385 Ravendale Drive
Mountain View, CA 94043 Mountain View, CA 94043
e-mail: kireeti@juniper.net e-mail: kireeti@juniper.net
Yakov Rekhter Yakov Rekhter
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/