< draft-gredler-spring-mpls-00.txt   draft-gredler-spring-mpls-01.txt >
Network Working Group Hannes Gredler Network Working Group Hannes Gredler
Internet Draft Juniper Networks Internet Draft Juniper Networks
Intended status: Standards Track Intended status: Standards Track
Expires: April 2014 Yakov Rekhter Expires: April 2014 Yakov Rekhter
Juniper Networks Juniper Networks
October 1 2013 Sriganesh Kini
Ericsson
October 20 2013
Supporting Source/Explicitly Routed Tunnels via Stacked LSPs Supporting Source/Explicitly Routed Tunnels via Stacked LSPs
draft-gredler-spring-mpls-00.txt draft-gredler-spring-mpls-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 3, line 11 skipping to change at page 3, line 11
This document also describes how use of IS-IS/OSPF as a label This document also describes how use of IS-IS/OSPF as a label
distribution protocol fits into the MPLS architecture. distribution protocol fits into the MPLS architecture.
Table of Contents Table of Contents
1 Specification of Requirements ......................... 3 1 Specification of Requirements ......................... 3
2 Terminology ........................................... 4 2 Terminology ........................................... 4
3 Introduction .......................................... 4 3 Introduction .......................................... 4
4 Constructing Explicitly Routed Tunnels by using Stacked LSPs 5 4 Constructing Explicitly Routed Tunnels by using Stacked LSPs 5
4.1 Examples of Constructing Explicitly Routed Tunnels by Stacked LSPs 7 4.1 Examples of Constructing Explicitly Routed Tunnels by Stacked LSPs 8
4.1.1 Explicitly Routed Tunnel with Strict Hops ............. 8 4.1.1 Explicitly Routed Tunnel with Single Hops ............. 8
4.1.2 Explicitly Routed Tunnel with Loose Hops .............. 10 4.1.2 Explicitly Routed Tunnel with Multi-Hops .............. 11
5 IS-IS or OSPF as Label Distribution Protocol .......... 12 5 IS-IS or OSPF as Label Distribution Protocol .......... 13
5.1 Example of IS-IS/OSPF as Label Distribution Protocols . 13 5.1 Example of IS-IS/OSPF as Label Distribution Protocols . 14
6 IANA Considerations ................................... 14 6 IANA Considerations ................................... 15
7 Security Considerations ............................... 14 7 Security Considerations ............................... 15
8 Acknowledgements ...................................... 14 8 Acknowledgements ...................................... 15
9 Normative References .................................. 14 9 Normative References .................................. 15
10 Informative References ................................ 14 10 Informative References ................................ 16
11 Authors' Addresses .................................... 15 11 Authors' Addresses .................................... 17
1. Specification of Requirements 1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
We use the term "explicitly routed tunnels" as a synonym for such We use the term "explicitly routed tunnels" as a synonym for such
terms as "source routed tunnels" and "source-initiated routed terms as "source routed tunnels" and "source-initiated routed
tunnels". tunnels".
Note that the term "source routed tunnel", or "source-initiated Note that the term "source routed tunnel", or "source-initiated
routed tunnel" does not imply that intermediate nodes of such a routed tunnel" does not imply that intermediate nodes of such a
tunnel forward packets traversing the tunnel based upon source tunnel forward packets traversing the tunnel based upon source
addresses of these packets. In the context of "source routed tunnels" addresses of these packets. In the context of "source routed tunnels"
and "source-initiated routed tunnels" the term "source" refers to the and "source-initiated routed tunnels" the term "source" refers to the
tunnels' ingress. tunnels' ingress.
This document assumes that a reader is familiar with the MPLS
architecture [RFC3031] terminology.
For a given Label Switched Path (LSP) of level m, as defined in
section 3.15 of [RFC3031]:
+ the ingress node/router is the LSR that pushes the level m label,
+ intermediate nodes/routers are the LSRs making their forwarding
decision on a level m label
3. Introduction 3. Introduction
MPLS architecture [RFC3031] defines the concept of explicitly routed MPLS architecture [RFC3031] defines the concept of explicitly routed
tunnel as follows: tunnel as follows:
If a Tunneled Packet travels from Ru to Rd over a path other If a Tunneled Packet travels from Ru to Rd over a path other
than the Hop-by-hop path, we say that it is in an "Explicitly than the Hop-by-hop path, we say that it is in an "Explicitly
Routed Tunnel" Routed Tunnel"
where Ru and Rd are Label Switch Routers (LSRs). where Ru and Rd are Label Switch Routers (LSRs).
To realize explicitly routed tunnels [RFC3031] proposes to use To realize explicitly routed tunnels [RFC3031] proposes to use
explicitly routed LSPs: explicitly routed Label Switched Paths (LSPs):
An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an
Explicitly Routed LSP Explicitly Routed LSP
Up until now there have been two possible protocols to instantiate/signal Up until now there have been two possible protocols to instantiate/signal
such explicitly routed LSPs - RSVP-TE ([RFC3209]) and CR-LDP such explicitly routed LSPs - RSVP-TE ([RFC3209]) and CR-LDP
([RFC3212]). ([RFC3212]).
MPLS architecture ([RFC3031]) defines the notion of LSP hierarchy, MPLS architecture ([RFC3031]) defines the notion of LSP hierarchy,
as LSP tunnels within LSPs. Use of MPLS label stack mechanism allows as LSP tunnels within LSPs. Use of MPLS label stack mechanism allows
LSP hierarchy to nest to any depth. LSP hierarchy to nest to any depth.
In this document we specify the procedures to realize explicitly In this document we specify the procedures to realize explicitly
routed point-to-point tunnels by using LSP hierarchy, thus defining routed point-to-point tunnels by using LSP hierarchy, thus defining
yet another possible mechanism to realize such tunnels. yet another possible mechanism to realize such tunnels. (Note though
that the idea of using LSP hierarchy to realize explicitly routed
tunnels is not new - e.g., Remote LFA [R-LFA] uses explicitly routed
tunnels constructed by LSP hierarchy.)
An essential part of MPLS is the notion of label distribution An essential part of MPLS is the notion of label distribution
protocol. On the subject of whether it should be one, or more then protocol. On the subject of whether it should be one, or more then
one label distribution protocol, MPLS architecture ([RFC3031]) said one label distribution protocol, MPLS architecture ([RFC3031]) said
the following: the following:
THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE
LABEL DISTRIBUTION PROTOCOL. In fact, a number of different LABEL DISTRIBUTION PROTOCOL. In fact, a number of different
label distribution protocols are being standardized. label distribution protocols are being standardized.
skipping to change at page 5, line 37 skipping to change at page 6, line 6
follows. follows.
Consider an explicitly routed point-to-point tunnel with an explicit Consider an explicitly routed point-to-point tunnel with an explicit
route <R(0), R(1), R(2), ... R(n)>, where R(0) is the ingress of the route <R(0), R(1), R(2), ... R(n)>, where R(0) is the ingress of the
tunnel and R(n) is the egress of the tunnel. Denote the LSPs needed tunnel and R(n) is the egress of the tunnel. Denote the LSPs needed
to realize such a tunnel via an LSP stack as <LSP(1), LSP(2), ... to realize such a tunnel via an LSP stack as <LSP(1), LSP(2), ...
LSP(n)>, where LSP(1) is the topmost and LSP(n) is the bottommost LSP LSP(n)>, where LSP(1) is the topmost and LSP(n) is the bottommost LSP
in the stack. These LSPs are constructed as follows: in the stack. These LSPs are constructed as follows:
+ All the LSPs in the stack are constructed with the same ingress - + All the LSPs in the stack are constructed with the same ingress -
R(0). R(0). (See further down on why this is needed.)
+ LSP(i) is constructed with R(i) as its egress (e.g., LSP(1) is + LSP(i) is constructed with R(i) as its egress (e.g., LSP(1) is
constructed with R(1) as its egress, LSP(2) with R(2) as its constructed with R(1) as its egress, LSP(2) with R(2) as its
egress, etc... LSP(n) with R(n) as its egress). egress, etc... LSP(n) with R(n) as its egress).
+ For every 0 < i < n, the first intermediate point of LSP(i+1). + For every 0 < i < n, the first intermediate router of LSP(i+1).
is constructed to be the egress of LSP(i). is constructed to be the same as the egress router of LSP(i).
+ The first intermediate point of LSP(1) is constructed to be one + The first intermediate router of LSP(1) is constructed to be one
hop away from R(0). If R(1) is one hop away from R(0), then this hop away from R(0). If R(1) is one hop away from R(0), then this
intermediate point is also the egress of LSP(1) (in which case intermediate router is also the egress of LSP(1) (in which case
LSP(1) is a one-hop LSP). If R(1) is more than one hop away from LSP(1) is a one-hop LSP). If R(1) is more than one hop away from
R(0), then this intermediate point is some router other than R(0), then this intermediate router is some router other than
R(1), and R(1) is still the egress of that LSP. R(1), and R(1) is still the egress of that LSP.
+ The first intermediate point of any LSP in the stack, could be + The first intermediate router of any LSP in the stack, could be
either single or multi-hop away from the egress of that LSP. either single or multi-hop away from the egress of that LSP.
When R(i) and R(i+1) are single hop away from each other, this + All the LSPs in the stack are constructed with the penultimate
corresponds to a strict hop for the explicitly routed tunnel, in hop popping. That is, for each LSP in the stack the penultimate
which case the first intermediate point of LSP(i+1) is one hop away router of that LSP pops the label corresponding to that LSP off
from the egress of that LSP. When R(i) and R(i+1) are multi-hop away the label stack before sending data to the egress router of that
from each other, this corresponds to a loose hop for the explicitly LSP.
routed tunnel, in which case the first intermediate point of LSP(i+1)
is multi-hop away from the egress of that LSP. When R(i) and R(i+1) are single hop away from each other, the first
intermediate router of LSP(i+1) is one hop away from the egress of
that LSP. When R(i) and R(i+1) are multi-hop away from each other,
the first intermediate router of LSP(i+1) is multi-hop away from the
egress of that LSP.
Following the above procedures, the LSPs in the stack satisfy the Following the above procedures, the LSPs in the stack satisfy the
following properties: following properties:
+ All LSPs in the stack have the same ingress. + All LSPs in the stack have the same ingress.
+ The egress of a given LSP in the stack is the first intermediate + The egress of a given LSP in the stack is the first intermediate
point of the next LSP in the stack. router of the next LSP in the stack.
+ The first intermediate point of the LSP at the top of the stack + The first intermediate router of the LSP at the top of the stack
is one hop away from the ingress. is one hop away from the ingress.
+ The first intermediate point of any LSP in the stack could be + The first intermediate router of any LSP in the stack could be
either single or multi-hop away from the egress of that LSP. either single or multi-hop away from the egress of that LSP.
(Thus the egress of a given LSP in the stack could be either (Thus the egress of a given LSP in the stack could be either
single or multi-hop away from the egress of the next LSP in the single or multi-hop away from the egress of the next LSP in the
stack.) stack.)
Such stack of LSPs provides the functionality to forward a packet Such stack of LSPs provides the functionality to forward a packet
through a sequence of egresses of the LSPs on the stack - the through a sequence of egresses of the LSPs on the stack - the
sequence of these egresses represents the explicit route of the sequence of these egresses represents the explicit route of the
explicitly routed point-to-point tunnel constructed by using these explicitly routed point-to-point tunnel constructed by using these
stacked LSPs. The ingress of all these LSPs is the ingress of the stacked LSPs. The ingress of all these LSPs is the ingress of the
tunnel. tunnel.
When the first intermediate point of a given LSP in the stack is When the first intermediate router of a given LSP in the stack is
multi-hop away from the egress of that LSP, the existing label multi-hop away from the egress of that LSP, the existing label
distribution protocols (LDP, RSVP-TE, etc. ) can be used to establish distribution protocols (LDP, RSVP-TE, etc. ) can be used to establish
a multi-hop LSP fragment for this LSP. When IS-IS or OSPF, in a multi-hop LSP fragment for this LSP. When IS-IS or OSPF, in
addition to being a routing protocol, is also used as a label addition to being a routing protocol, is also used as a label
distribution protocol (see section "IS-IS or OSPF as Label distribution protocol (see section "IS-IS or OSPF as Label
Distribution Protocol"), it can also be used to establish such multi- Distribution Protocol"), it can also be used to establish such multi-
hop LSP fragment. hop LSP fragment.
To construct the label stack associated with the stack of LSPs the To construct the label stack associated with the stack of LSPs the
ingress uses the following procedures: ingress of all these LSPs, R0, uses the following procedures:
+ For (n > i > 0) R(0) obtains from R(i) label binding for LSP(i+1) + For (n > i > 0) R(0) obtains from R(i) label binding for LSP(i+1)
and places the label onto the stack, starting from the bottommost and places the label onto the stack, starting from the bottommost
label (the label that corresponds to LSP(n). label (the label that corresponds to LSP(n).
In section "IS-IS or OSPF as Label Distribution Protocol" we In section "IS-IS or OSPF as Label Distribution Protocol" we
describe how IS-IS or OSPF with appropriate extensions could be describe how IS-IS or OSPF with appropriate extensions could be
used as a label distribution protocol to obtain such label used as a label distribution protocol to obtain such label
bindings. bindings.
If the first intermediate point of LSP(i+1) is either (a) a If the first intermediate router of LSP(i+1) is either (a) a
single hop away from the egress of that LSP, or (b) multi-hop single hop away from the egress of that LSP, or (b) multi-hop
away, and LDP is used as a label distribution protocol to away, and LDP is used as a label distribution protocol to
establish a multi-hop LSP fragment between the first intermediate establish a multi-hop LSP fragment between the first intermediate
point and the egress of that LSP, then R(0) can use targeted LDP router and the egress of that LSP, then R(0) can use targeted LDP
session with R(i) to obtain such label bindings. session with R(i) to obtain such label bindings.
+ For LSP(1) if R(1) is one hop away from R(0), then no label is + For LSP(1) if R(1) is one hop away from R(0), then no label is
needed, and the label stack construction terminates with the needed (as LSP(1), just like all other LSPs in the stack, is
topmost label that R(0) obtains from R(1) for LSP(2). constructed with the penultimate hop popping), and the label
stack construction terminates with the topmost label that R(0)
obtains from R(1) for LSP(2).
+ Otherwise, if R(1) is more than one hop away from R(0), then R(0) + Otherwise, if R(1) is more than one hop away from R(0), then R(0)
places the label it binds to LSP(1) at the top of the stack. obtains label binding for LSP(1) from the first intermediate
router of LSP(1), and places this label at the top of the stack.
Note that the above procedures require all the LSPs in the stack to
have the same ingress - R(0). This requirement comes from the
observation that (a) R(0) is the router that constructs the whole
label stack needed to realize the explicitly routed tunnel, and (b)
according to MPLS architecture [RFC3031] when a router wants to
create a label stack, the router has to be the head-end of all the
LSPs corresponding to the labels in the stack.
Since the MPLS label stack mechanism allows stack of LSPs to nest to Since the MPLS label stack mechanism allows stack of LSPs to nest to
any depth, use of LSP hierarchy for explicitly routed tunnels does any depth, use of LSP hierarchy for explicitly routed tunnels does
not place any protocol restrictions on the number of entries in the not place any protocol restrictions on the number of entries in the
explicit route of an explicitly routed tunnel. Note though that there explicit route of an explicitly routed tunnel. Note though that there
may be some other restrictions (e.g., due to MTU, or hardware) that may be some other restrictions (e.g., due to MTU, or hardware) that
would place an upper bound on the depth of the label stack, and thus would place an upper bound on the depth of the label stack, and thus
on the number of entries in the explicit route. Also, the depth of on the number of entries in the explicit route. Also, the depth of
the label stack may have implications on ECMP, and specifically on the label stack may have implications on ECMP, and specifically on
the use of the Entropy label (see [kini] for more). the use of the Entropy label (see [kini] for more).
4.1. Examples of Constructing Explicitly Routed Tunnels by Stacked LSPs 4.1. Examples of Constructing Explicitly Routed Tunnels by Stacked LSPs
In this section we illustrate how to construct an explicitly routed In this section we illustrate how to construct an explicitly routed
tunnel by using stacked LSPs. The first example illustrates this for tunnel by using stacked LSPs. The first example illustrates this for
an explicitly routed tunnel with strict hops. The second example an explicitly routed tunnel where consecutive hops that define the
illustrates this for an explicitly routed tunnel with loose hops. tunnel are one hop away from each other. The second example
illustrates this when these hops are more than one hop away from each
other.
4.1.1. Explicitly Routed Tunnel with Strict Hops 4.1.1. Explicitly Routed Tunnel with Single Hops
Consider a network topology shown below: Consider a network topology shown below:
R0-----R4 R0-----R4
| /| | /|
| / | | / |
| / | | / |
| / | | / |
| / | | / |
R1 R3 R1 R3
\ / \ /
\ / \ /
R2 R2
Assume that R0 wants to construct an explicitly routed tunnel with Assume that R0 wants to construct an explicitly routed tunnel with
(R0, R1, R2, R3, R4) as strict hops. R0 constructs this tunnel using (R0, R1, R2, R3, R4). The consecutive hops that define the tunnel are
the following stack of LSPs: one hop away from each other. That is, R0 is one hop away from R1, R2
is one hop away from R1, R3 is one hop away from R2, and R4 is one
hop away from R3.
R0 constructs this tunnel using the following stack of LSPs:
LSP1: (R0, R1) - top of the stack LSP1: (R0, R1) - top of the stack
LSP2: (R0, R1, R2) LSP2: (R0, R1, R2)
LSP3: (R0, R2, R3) LSP3: (R0, R2, R3)
LSP4: (R0, R3, R4) - bottom of the stack LSP4: (R0, R3, R4) - bottom of the stack
Note that this stack of LSPs meets the requirements specified in Note that this stack of LSPs meets the requirements specified in
section "Constructing Explicitly Routed Tunnels by using Stacked section "Constructing Explicitly Routed Tunnels by using Stacked
LSPs". Specifically, LSPs". Specifically,
+ All four LSPs in the stack have the same ingress - R0, which is + All four LSPs in the stack have the same ingress - R0, which is
also the ingress of the explicitly routed tunnel. also the ingress of the explicitly routed tunnel.
+ The egress of LSP1, R1, is the first intermediate point of the + The egress of LSP1, R1, is the first intermediate router of the
next LSP in the stack, LSP2. The egress of LSP2, R2, is the first next LSP in the stack, LSP2. The egress of LSP2, R2, is the first
intermediate point of the next LSP in the stack, LSP3. Likewise, intermediate router of the next LSP in the stack, LSP3. Likewise,
the egress of LSP3, R3, is the first intermediate point of the the egress of LSP3, R3, is the first intermediate router of the
next (and the last) LSP in the stack, LSP4. next (and the last) LSP in the stack, LSP4.
+ The LSP at the top of the stack, LSP1, has its first intermediate + The LSP at the top of the stack, LSP1, has its first intermediate
point, R1, one hop away from its ingress, R0. Because of that, router, R1, one hop away from its ingress, R0. Because of that,
this intermediate point is also the egress of that LSP, and that this intermediate router is also the egress of that LSP, and that
LSP is a one-hop LSP. LSP is a one-hop LSP.
+ In that particular example the first intermediate point of every + In that particular example the first intermediate router of every
LSP in the stack is one hop away from the egress of that LSP. LSP in the stack is one hop away from the egress of that LSP.
That is, the first intermediate point of LSP2, R1, is one hop That is, the first intermediate router of LSP2, R1, is one hop
away from the egress of that LSP, R2; the first intermediate away from the egress of that LSP, R2; the first intermediate
point of LSP3, R2, is one hop away from the egress of that LSP, router of LSP3, R2, is one hop away from the egress of that LSP,
R3; and the first intermediate point of LSP4, R3, is one hop away R3; and the first intermediate router of LSP4, R3, is one hop
from the egress of that LSP, R4. As a result, the egress of a away from the egress of that LSP, R4. As a result, the egress of
given LSP in the stack is one hop away from the egress of the a given LSP in the stack is one hop away from the egress of the
next LSP in the stack, which makes all the hops of the explicitly next LSP in the stack.
routed tunnel strict.
The first intermediate point of each of these LSPs creates label The first intermediate router of each of these LSPs creates label
bindings for these LSPs as follows. R3 creates label binding for LSP4 bindings for these LSPs as follows. R3 creates label binding for LSP4
by binding a particular label, L1, to the address of R4, creating a by binding a particular label, L1, to the address of R4, creating a
Next Hop Label Forwarding Entry (NHLFE) whose next hop is the link Next Hop Label Forwarding Entry (NHLFE) whose next hop is the link
from R3 to R4, and setting the Incoming Label Map (ILM) so that L1 from R3 to R4, and setting the Incoming Label Map (ILM) so that L1
maps to that NHLFE. Likewise, R2 creates label binding for LSP3 by maps to that NHLFE. Likewise, R2 creates label binding for LSP3 by
binding a particular label, L2, to the address of R3, creating an binding a particular label, L2, to the address of R3, creating an
NHLFE whose next hop is the link from R2 to R3, and setting the ILM NHLFE whose next hop is the link from R2 to R3, and setting the ILM
so that L2 maps to that NHLFE. Finally, R1 creates label binding for so that L2 maps to that NHLFE. Finally, R1 creates label binding for
LSP2 by binding a particular label, L3, to the address of R2, LSP2 by binding a particular label, L3, to the address of R2,
creating an NHLFE whose next hop is the link from R1 to R2, and creating an NHLFE whose next hop is the link from R1 to R2, and
skipping to change at page 9, line 47 skipping to change at page 10, line 34
+ Step 2: R0 obtains label binding L2 created by R2 for LSP3 (R0, + Step 2: R0 obtains label binding L2 created by R2 for LSP3 (R0,
R2, R3), and pushes L2 into the stack. At this point the stack R2, R3), and pushes L2 into the stack. At this point the stack
contains (L2, L1). contains (L2, L1).
+ Step 3: R0 obtains label binding L3 created by R1 for LSP2 (R0, + Step 3: R0 obtains label binding L3 created by R1 for LSP2 (R0,
R1, R2), and pushes L3 into the stack. At this point the stack R1, R2), and pushes L3 into the stack. At this point the stack
contains (L3, L2, L1). contains (L3, L2, L1).
+ Step 4: Since R0 and R1 are one hop away from each other the + Step 4: Since R0 and R1 are one hop away from each other the
label stack construction is completed (R0 does not need a label label stack construction is completed (R0 does not need a label
for one-hop LSP1). for one-hop LSP1, as all the LSPs use penultimate hop popping).
So far we did not say anything about how R0 obtains from R3 label So far we did not say anything about how R0 obtains from R3 label
binding for LSP4, from R2 label binding for LSP3, and from R1 label binding for LSP4, from R2 label binding for LSP3, and from R1 label
binding for LSP2. binding for LSP2.
At least in principle, these label bindings could be obtain by such At least in principle, these label bindings could be obtain by such
already defined label distribution protocols as LDP (to be more already defined label distribution protocols as LDP (to be more
precise, targeted LDP if the two routers are more than one hop away precise, targeted LDP if the two routers are more than one hop away
from each other). E.g., if one uses targeted LDP, then R0 would need from each other). E.g., if one uses targeted LDP, then R0 would need
to maintain a targeted LDP session with R3 and another targeted LDP to dynamically establish and maintain a targeted LDP session with R3
session with R2 (R0 would maintain a "vanilla" LDP session with R1). and another targeted LDP session with R2 (R0 would maintain a
Using these LDP sessions R0 would obtain from R3 label binding for "vanilla" LDP session with R1). Using these LDP sessions R0 would
LSP4, from R2 label binding for LSP3, and from R1 label binding for obtain from R3 label binding for LSP4, from R2 label binding for
LSP2. LSP3, and from R1 label binding for LSP2. Note that obtaining such
labels bindings with targeted LDP may also require defining a new FEC
to be used by targeted LDP.
In section "IS-IS or OSPF as Label Distribution Protocol" we describe In section "IS-IS or OSPF as Label Distribution Protocol" we describe
how IS-IS or OSPF with appropriate extensions could be used as a how IS-IS or OSPF with appropriate extensions could be used as a
label distribution protocol to obtain such label bindings. label distribution protocol to obtain such label bindings.
4.1.2. Explicitly Routed Tunnel with Loose Hops When R0 wants to forward a packet along the explicitly constructed
tunnel (R0, R1, R2, R3, R4), R0 pushes (L3, L2, L1) onto the label
stack of the packet, and forwards the packet to R1. R1 performs the
lookup on the topmost label, L3, and based on this lookup forwards
the packet to R2. Prior to forwarding the packet to R2, R1 (acting as
a penultimate hop for LSP2) pops the topmost label, L3. When R2
receives the packet, R2 performs the lookup on the topmost label, L2,
and based on this lookup forwards the packet to R3. Prior to
forwarding the packet to R3, R2 (acting as a penultimate hop for
LSP3) pops the topmost label, L2. When R3 receives the packet, R3
performs the lookup on the topmost label, L1, and based on this
lookup forwards the packet to R4. Prior to forwarding the packet to
R4, R3 (acting as a penultimate hop for LSP4) pops the topmost label,
L1.
4.1.2. Explicitly Routed Tunnel with Multi-Hops
Consider a network topology shown below: Consider a network topology shown below:
R0---R1 R0---R1
/ \ / \
R2 R5---R6 R2 R5---R6
\ / \ /
R3---R4 R3---R4
Assume that R0 wants to construct an explicitly routed tunnel with Assume that R0 wants to construct an explicitly routed tunnel with
(R0, R4, R6) as loose hops. R0 constructs this tunnel using the (R0, R4, R6) as hops. Note that R4 is multi-hop away from R0, and R6
following stack of LSPs: is multi-hop away from R4.
R0 constructs this tunnel using the following stack of LSPs:
LSP1: (R0, R2, R3, R4) - top of the stack LSP1: (R0, R2, R3, R4) - top of the stack
LSP2: (R0, R4, R5, R6) - bottom of the stack LSP2: (R0, R4, R5, R6) - bottom of the stack
Note that this stack of LSPs meets the requirements specified in Note that this stack of LSPs meets the requirements specified in
section "Constructing Explicitly Routed Tunnels by using Stacked section "Constructing Explicitly Routed Tunnels by using Stacked
LSPs". Specifically, LSPs". Specifically,
+ Both LSPs in the stack have the same ingress - R0, which is also + Both LSPs in the stack have the same ingress - R0, which is also
the ingress of the explicitly routed tunnel. the ingress of the explicitly routed tunnel.
+ The egress of LSP1, R4, is the first intermediate point of the + The egress of LSP1, R4, is the first intermediate router of the
next LSP in the stack, LSP2. next LSP in the stack, LSP2.
+ The LSP at the top of the stack, LSP1, has its first intermediate + The LSP at the top of the stack, LSP1, has its first intermediate
point, R2, one hop away from its ingress, R0. However, this router, R2, one hop away from its ingress, R0. However, this
intermediate point is not the egress of that LSP, and therefore intermediate router is not the egress of that LSP, and therefore
this LSP is a multi-hop LSP. this LSP is a multi-hop LSP.
+ In that particular example the first intermediate point of every + In that particular example the first intermediate router of every
LSP in the stack is multi-hop away from the egress of that LSP LSP in the stack is multi-hop away from the egress of that LSP.
That is, the first intermediate point of LSP1, R2, is multi-hop That is, the first intermediate router of LSP1, R2, is multi-hop
away from the egress of that LSP, R4; the first intermediate away from the egress of that LSP, R4; the first intermediate
point of LSP2, R4, is multi-hop away from the egress of that LSP, router of LSP2, R4, is multi-hop away from the egress of that
R6. As a result, the egress of a given LSP in the stack is LSP, R6. As a result, the egress of a given LSP in the stack is
multi-hop away from the egress of the next LSP in the stack, multi-hop away from the egress of the next LSP in the stack.
which makes the hops of the explicitly routed tunnel loose.
In this example we assume that LDP is used as a label distribution In this example we assume that LDP is used as a label distribution
protocol for both LSP1 and LSP2. Since R0 and R4 are not IGP protocol for both LSP1 and LSP2. Since R0 and R4 are not IGP
neighbors, they are remote label distribution peers. Thus R0 and R4 neighbors, they are remote label distribution peers. Thus R0 and R4
use targeted LDP for label distribution. All other routers use use targeted LDP for label distribution. All other routers use
"vanilla" LDP procedures. "vanilla" LDP procedures.
To get from the first hop of LSP2, R0, to its second hop, R4, the To get from the first hop of LSP2, R0, to its second hop, R4, the
packet has to go through the LSP tunnel provided by LSP1. packet has to go through the LSP tunnel provided by LSP1.
skipping to change at page 11, line 49 skipping to change at page 13, line 4
+ Step 3: Since R0 and R1 are one hop away from each other the + Step 3: Since R0 and R1 are one hop away from each other the
label stack construction is completed (R0 does not need a label label stack construction is completed (R0 does not need a label
for one-hop LSP1). for one-hop LSP1).
A reader familiar with Remote LFA FRR [R-LFA] should be able to A reader familiar with Remote LFA FRR [R-LFA] should be able to
notice that the example described in this section is nothing more notice that the example described in this section is nothing more
than an instance of Remote LFA FRR, where Remote LFA FRR provides than an instance of Remote LFA FRR, where Remote LFA FRR provides
fast reroute to the traffic going from R0 to R6 in the presence of fast reroute to the traffic going from R0 to R6 in the presence of
the (R0, R2) link failure, with R0 being the Point of Local Repair the (R0, R2) link failure, with R0 being the Point of Local Repair
(PLR), R4 being the PQ-node, and R6 being the ultimate destination. (PLR), R4 being the PQ-node, and R6 being the ultimate destination.
The explicitly routed tunnel (R0, R4, R6) consists of the PLR as the The explicitly routed tunnel (R0, R4, R6) consists of the PLR as the
head-node, the PQ-node as the next loose hop, and the ultimate head-node, the PQ-node as the next hop, and the ultimate destination
destination as yet another loose hop. as yet another hop.
5. IS-IS or OSPF as Label Distribution Protocol 5. IS-IS or OSPF as Label Distribution Protocol
When OSPF or IS-IS, in addition to being a routing protocol, is also When OSPF or IS-IS, in addition to being a routing protocol, is also
used as a label distribution protocol (as proposed in [gredler-isis], used as a label distribution protocol (as proposed in [gredler-isis],
[gredler-ospf], [previdi-isis], [psenak-ospf), the OSPF/IS-IS Link [gredler-ospf], [previdi-isis], [psenak-ospf), the OSPF/IS-IS Link
State Advertisements originated by a router carry label bindings for State Advertisements originated by a router carry label bindings for
LSPs that either transit or originated by the router. Doing this LSPs that either transit or originated by the router. Doing this
allows to extend such LSPs. The criteria for selecting among all allows to extend such LSPs. The criteria for selecting among all
these LSPs a subset for which the router would originate label these LSPs a subset for which the router would originate label
skipping to change at page 13, line 33 skipping to change at page 14, line 35
by using the index advertised by R3 as an offset into the label block by using the index advertised by R3 as an offset into the label block
advertised by R2. Note that to avoid wasting labels this scheme advertised by R2. Note that to avoid wasting labels this scheme
requires a fairly dense assignment of indices. Also note that to requires a fairly dense assignment of indices. Also note that to
expand the number of labels that a router advertises using label expand the number of labels that a router advertises using label
blocks, the router may advertise more than one label block. blocks, the router may advertise more than one label block.
Note though, that the benefits of scaling improvements in terms of Note though, that the benefits of scaling improvements in terms of
label distribution peering come at a cost, as every router in the label distribution peering come at a cost, as every router in the
domain ends up keeping all the labels assigned/bounded by every other domain ends up keeping all the labels assigned/bounded by every other
router in the domain, whether it really needs to know them or not. router in the domain, whether it really needs to know them or not.
Whether this cost is of practical significance depends on the Whether this cost is of practical significance depends on (a) the
encoding of label bindings (e.g., use of label blocks vs enumerating number of label bindings being advertised, and (b) the encoding of
each label binding). label bindings (e.g., use of label blocks vs enumerating each label
binding).
5.1. Example of IS-IS/OSPF as Label Distribution Protocols 5.1. Example of IS-IS/OSPF as Label Distribution Protocols
In this section we illustrate how IS-IS/OSPF with extensions, as In this section we illustrate how IS-IS/OSPF with extensions, as
defined in [gredler-isis], [gredler-ospf], [previdi-isis], [psenak- defined in [gredler-isis], [gredler-ospf], [previdi-isis], [psenak-
ospf] could be used as a label distribution protocol to support ospf] could be used as a label distribution protocol to support
explicitly routed tunnels realized by stacked LSPs. For the purpose explicitly routed tunnels realized by stacked LSPs. For the purpose
of this illustration we assume the scenario described in section of this illustration we assume the scenario described in section
"Example of Constructing Explicitly Routed Tunnels by Stacked LSPs". "Example of Constructing Explicitly Routed Tunnels by Stacked LSPs".
In that example one of the key issues is the ability of R0 to obtain In that example one of the key issues is the ability of R0 to obtain
skipping to change at page 14, line 29 skipping to change at page 15, line 33
6. IANA Considerations 6. IANA Considerations
This document introduces no new IANA Considerations. This document introduces no new IANA Considerations.
7. Security Considerations 7. Security Considerations
TBD TBD
8. Acknowledgements 8. Acknowledgements
We would like to thank John Drake and John Scudder for their review We would like to thank John Drake (Juniper Networks) and John Scudder
(Juniper Networks) for their review and comments.
We would also like to thank Bruno Decraene (Orange) for his review
and comments. and comments.
9. Normative References 9. Normative References
[RFC3031] Rosen, E., et. al., "Multiprotocol Label Switching [RFC3031] Rosen, E., et. al., "Multiprotocol Label Switching
Architecture", RFC3031, January 2001 Architecture", RFC3031, January 2001
10. Informative References 10. Informative References
[kini] Kini, S., et. al., "Entropy labels for source routed stacked [kini] Kini, S., et. al., "Entropy labels for source routed stacked
skipping to change at line 630 skipping to change at page 17, line 14
11. Authors' Addresses 11. Authors' Addresses
Hannes Gredler Hannes Gredler
Juniper Networks Juniper Networks
e-mail: hannes@juniper.net e-mail: hannes@juniper.net
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
e-mail: yakov@juniper.net e-mail: yakov@juniper.net
Sriganesh Kini
Ericsson
Email: sriganesh.kini@ericsson.com
 End of changes. 45 change blocks. 
83 lines changed or deleted 143 lines changed or added

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