draft-ietf-mpls-arch-03.txt   draft-ietf-mpls-arch-04.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Arun Viswanathan Arun Viswanathan
Lucent Technologies Lucent Technologies
Ross Callon Ross Callon
IronBridge Networks, Inc. IronBridge Networks, Inc.
February 1999 February 1999
Multiprotocol Label Switching Architecture Multiprotocol Label Switching Architecture
draft-ietf-mpls-arch-03.txt draft-ietf-mpls-arch-04.txt
Status of this Memo 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 18 skipping to change at page 2, line 18
1.1 Overview ........................................... 4 1.1 Overview ........................................... 4
1.2 Terminology ........................................ 6 1.2 Terminology ........................................ 6
1.3 Acronyms and Abbreviations ......................... 9 1.3 Acronyms and Abbreviations ......................... 9
1.4 Acknowledgments .................................... 10 1.4 Acknowledgments .................................... 10
2 MPLS Basics ........................................ 10 2 MPLS Basics ........................................ 10
2.1 Labels ............................................. 10 2.1 Labels ............................................. 10
2.2 Upstream and Downstream LSRs ....................... 11 2.2 Upstream and Downstream LSRs ....................... 11
2.3 Labeled Packet ..................................... 11 2.3 Labeled Packet ..................................... 11
2.4 Label Assignment and Distribution .................. 11 2.4 Label Assignment and Distribution .................. 11
2.5 Attributes of a Label Binding ...................... 12 2.5 Attributes of a Label Binding ...................... 12
2.6 Label Distribution Protocol (LDP) .................. 12 2.6 Label Distribution Protocols ....................... 12
2.7 Downstream vs. Downstream-on-Demand ................ 12 2.7 Downstream vs. Downstream-on-Demand ................ 12
2.8 Label Retention Mode ............................... 13 2.8 Label Retention Mode ............................... 13
2.9 The Label Stack .................................... 13 2.9 The Label Stack .................................... 13
2.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 14 2.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 14
2.11 Incoming Label Map (ILM) ........................... 15 2.11 Incoming Label Map (ILM) ........................... 15
2.12 FEC-to-NHLFE Map (FTN) ............................. 15 2.12 FEC-to-NHLFE Map (FTN) ............................. 15
2.13 Label Swapping ..................................... 15 2.13 Label Swapping ..................................... 15
2.14 Scope and Uniqueness of Labels ..................... 15 2.14 Scope and Uniqueness of Labels ..................... 16
2.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 17 2.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 17
2.16 Penultimate Hop Popping ............................ 18 2.16 Penultimate Hop Popping ............................ 18
2.17 LSP Next Hop ....................................... 20 2.17 LSP Next Hop ....................................... 20
2.18 Invalid Incoming Labels ............................ 20 2.18 Invalid Incoming Labels ............................ 20
2.19 LSP Control: Ordered versus Independent ............ 21 2.19 LSP Control: Ordered versus Independent ............ 21
2.20 Aggregation ........................................ 22 2.20 Aggregation ........................................ 22
2.21 Route Selection .................................... 23 2.21 Route Selection .................................... 23
2.22 Lack of Outgoing Label ............................. 24 2.22 Lack of Outgoing Label ............................. 24
2.23 Time-to-Live (TTL) ................................. 24 2.23 Time-to-Live (TTL) ................................. 25
2.24 Loop Control ....................................... 26 2.24 Loop Control ....................................... 26
2.25 Label Encodings .................................... 26 2.25 Label Encodings .................................... 26
2.25.1 MPLS-specific Hardware and/or Software ............. 26 2.25.1 MPLS-specific Hardware and/or Software ............. 27
2.25.2 ATM Switches as LSRs ............................... 27 2.25.2 ATM Switches as LSRs ............................... 27
2.25.3 Interoperability among Encoding Techniques ......... 28 2.25.3 Interoperability among Encoding Techniques ......... 28
2.26 Label Merging ...................................... 29 2.26 Label Merging ...................................... 29
2.26.1 Non-merging LSRs ................................... 30 2.26.1 Non-merging LSRs ................................... 30
2.26.2 Labels for Merging and Non-Merging LSRs ............ 30 2.26.2 Labels for Merging and Non-Merging LSRs ............ 31
2.26.3 Merge over ATM ..................................... 31 2.26.3 Merge over ATM ..................................... 31
2.26.3.1 Methods of Eliminating Cell Interleave ............. 31 2.26.3.1 Methods of Eliminating Cell Interleave ............. 31
2.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 32 2.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 32
2.27 Tunnels and Hierarchy .............................. 33 2.27 Tunnels and Hierarchy .............................. 33
2.27.1 Hop-by-Hop Routed Tunnel ........................... 33 2.27.1 Hop-by-Hop Routed Tunnel ........................... 33
2.27.2 Explicitly Routed Tunnel ........................... 33 2.27.2 Explicitly Routed Tunnel ........................... 33
2.27.3 LSP Tunnels ........................................ 33 2.27.3 LSP Tunnels ........................................ 34
2.27.4 Hierarchy: LSP Tunnels within LSPs ................. 34 2.27.4 Hierarchy: LSP Tunnels within LSPs ................. 34
2.27.5 LDP Peering and Hierarchy .......................... 34 2.27.5 Label Distribution Peering and Hierarchy ........... 35
2.28 LDP Transport ...................................... 36 2.28 Label Distribution Protocol Transport .............. 36
2.29 Multicast .......................................... 36 2.29 Why More than one Label Distribution Protocol? ..... 36
3 Some Applications of MPLS .......................... 36 2.29.1 BGP and LDP ........................................ 37
3.1 MPLS and Hop by Hop Routed Traffic ................. 36 2.29.2 Labels for RSVP Flowspecs .......................... 37
3.1.1 Labels for Address Prefixes ........................ 36 2.29.3 Labels for Explicitly Routed LSPs .................. 37
3.1.2 Distributing Labels for Address Prefixes ........... 37 2.30 Multicast .......................................... 38
3.1.2.1 LDP Peers for a Particular Address Prefix .......... 37 3 Some Applications of MPLS .......................... 38
3.1.2.2 Distributing Labels ................................ 37 3.1 MPLS and Hop by Hop Routed Traffic ................. 38
3.1.3 Using the Hop by Hop path as the LSP ............... 38 3.1.1 Labels for Address Prefixes ........................ 38
3.1.4 LSP Egress and LSP Proxy Egress .................... 39 3.1.2 Distributing Labels for Address Prefixes ........... 38
3.1.5 The Implicit NULL Label ............................ 39 3.1.2.1 Label Distribution Peers for an Address Prefix ..... 38
3.1.6 Option: Egress-Targeted Label Assignment ........... 40 3.1.2.2 Distributing Labels ................................ 39
3.2 MPLS and Explicitly Routed LSPs .................... 42 3.1.3 Using the Hop by Hop path as the LSP ............... 40
3.2.1 Explicitly Routed LSP Tunnels ...................... 42 3.1.4 LSP Egress and LSP Proxy Egress .................... 40
3.3 Label Stacks and Implicit Peering .................. 43 3.1.5 The Implicit NULL Label ............................ 41
3.4 MPLS and Multi-Path Routing ........................ 44 3.1.6 Option: Egress-Targeted Label Assignment ........... 42
3.5 LSP Trees as Multipoint-to-Point Entities .......... 44 3.2 MPLS and Explicitly Routed LSPs .................... 43
3.6 LSP Tunneling between BGP Border Routers ........... 45 3.2.1 Explicitly Routed LSP Tunnels ...................... 43
3.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 46 3.3 Label Stacks and Implicit Peering .................. 44
3.8 MPLS and Multicast ................................. 47 3.4 MPLS and Multi-Path Routing ........................ 45
4 LDP Procedures for Hop-by-Hop Routed Traffic ....... 47 3.5 LSP Trees as Multipoint-to-Point Entities .......... 45
4.1 The Procedures for Advertising and Using labels .... 47 3.6 LSP Tunneling between BGP Border Routers ........... 46
4.1.1 Downstream LSR: Distribution Procedure ............. 48 3.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 48
4.1.1.1 PushUnconditional .................................. 48 3.8 MPLS and Multicast ................................. 48
4.1.1.2 PushConditional .................................... 49 4 Label Distribution Procedures (Hop-by-Hop) ......... 49
4.1.1.3 PulledUnconditional ................................ 49 4.1 The Procedures for Advertising and Using labels .... 49
4.1.1.4 PulledConditional .................................. 50 4.1.1 Downstream LSR: Distribution Procedure ............. 50
4.1.2 Upstream LSR: Request Procedure .................... 50 4.1.1.1 PushUnconditional .................................. 50
4.1.2.1 RequestNever ....................................... 51 4.1.1.2 PushConditional .................................... 50
4.1.2.2 RequestWhenNeeded .................................. 51 4.1.1.3 PulledUnconditional ................................ 51
4.1.2.3 RequestOnRequest ................................... 51 4.1.1.4 PulledConditional .................................. 51
4.1.3 Upstream LSR: NotAvailable Procedure ............... 51 4.1.2 Upstream LSR: Request Procedure .................... 52
4.1.3.1 RequestRetry ....................................... 52 4.1.2.1 RequestNever ....................................... 52
4.1.3.2 RequestNoRetry ..................................... 52 4.1.2.2 RequestWhenNeeded .................................. 53
4.1.4 Upstream LSR: Release Procedure .................... 52 4.1.2.3 RequestOnRequest ................................... 53
4.1.4.1 ReleaseOnChange .................................... 52 4.1.3 Upstream LSR: NotAvailable Procedure ............... 53
4.1.4.2 NoReleaseOnChange .................................. 52 4.1.3.1 RequestRetry ....................................... 53
4.1.5 Upstream LSR: labelUse Procedure ................... 53 4.1.3.2 RequestNoRetry ..................................... 54
4.1.5.1 UseImmediate ....................................... 53 4.1.4 Upstream LSR: Release Procedure .................... 54
4.1.5.2 UseIfLoopNotDetected ............................... 53 4.1.4.1 ReleaseOnChange .................................... 54
4.1.6 Downstream LSR: Withdraw Procedure ................. 53 4.1.4.2 NoReleaseOnChange .................................. 54
4.2 MPLS Schemes: Supported Combinations of Procedures . 54 4.1.5 Upstream LSR: labelUse Procedure ................... 54
4.2.1 Schemes for LSRs that Support Label Merging ........ 55 4.1.5.1 UseImmediate ....................................... 55
4.2.2 Schemes for LSRs that do not Support Label Merging . 56 4.1.5.2 UseIfLoopNotDetected ............................... 55
4.2.3 Interoperability Considerations .................... 57 4.1.6 Downstream LSR: Withdraw Procedure ................. 55
5 Security Considerations ............................ 58 4.2 MPLS Schemes: Supported Combinations of Procedures . 56
6 Intellectual Property .............................. 58 4.2.1 Schemes for LSRs that Support Label Merging ........ 56
7 Authors' Addresses ................................. 58 4.2.2 Schemes for LSRs that do not Support Label Merging . 58
8 References ......................................... 59 4.2.3 Interoperability Considerations .................... 59
5 Security Considerations ............................ 60
6 Intellectual Property .............................. 60
7 Authors' Addresses ................................. 60
8 References ......................................... 61
1. Introduction to MPLS 1. Introduction to MPLS
1.1. Overview 1.1. Overview
As a packet of a connectionless network layer protocol travels from As a packet of a connectionless network layer protocol travels from
one router to the next, each router makes an independent forwarding one router to the next, each router makes an independent forwarding
decision for that packet. That is, each router analyzes the packet's decision for that packet. That is, each router analyzes the packet's
header, and each router runs a network layer routing algorithm. Each header, and each router runs a network layer routing algorithm. Each
router independently chooses a next hop for the packet, based on its router independently chooses a next hop for the packet, based on its
skipping to change at page 12, line 13 skipping to change at page 12, line 13
that it only binds labels that are in that range. that it only binds labels that are in that range.
2.5. Attributes of a Label Binding 2.5. Attributes of a Label Binding
A particular binding of label L to FEC F, distributed by Rd to Ru, A particular binding of label L to FEC F, distributed by Rd to Ru,
may have associated "attributes". If Ru, acting as a downstream LSR, may have associated "attributes". If Ru, acting as a downstream LSR,
also distributes a binding of a label to FEC F, then under certain also distributes a binding of a label to FEC F, then under certain
conditions, it may be required to also distribute the corresponding conditions, it may be required to also distribute the corresponding
attribute that it received from Rd. attribute that it received from Rd.
2.6. Label Distribution Protocol (LDP) 2.6. Label Distribution Protocols
A Label Distribution Protocol (LDP) is a set of procedures by which A label distribution protocol is a set of procedures by which one LSR
one LSR informs another of the label/FEC bindings it has made. Two informs another of the label/FEC bindings it has made. Two LSRs
LSRs which use an LDP to exchange label/FEC binding information are which use a label distribution protocol to exchange label/FEC binding
known as "LDP Peers" with respect to the binding information they information are known as "label distribution peers" with respect to
exchange. If two LSRs are LDP Peers, we will speak of there being an the binding information they exchange. If two LSRs are label
"LDP Adjacency" between them. distribution peers, we will speak of there being a "label
distribution adjacency" between them.
(N.B.: two LSRs may be LDP Peers with respect to some set of (N.B.: two LSRs may be label distribution peers with respect to some
bindings, but not with respect to some other set of bindings.) set of bindings, but not with respect to some other set of bindings.)
The LDP also encompasses any negotiations in which two LDP Peers need The label distribution protocol also encompasses any negotiations in
to engage in order to learn of each other's MPLS capabilities. which two label distribution peers need to engage in order to learn
of each other's MPLS capabilities.
The architecture does not assume that there is only a single Label THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL
Distribution Protocol. Different label distribution protocols might DISTRIBUTION PROTOCOL. In fact, a number of different label
be used for different purposes or in different environments. See, distribution protocols are being standardized. Existing protocols
e.g., [MPLS-LDP], [MPLS-BGP], [MPLS-RSVP], [MPLS-RSVP-TUNNELS], etc. have been extended so that label distribution can be piggybacked on
them (see, e.g., [MPLS-BGP], [MPLS-RSVP], [MPLS-RSVP-TUNNELS]). New
protocols have also been defined for the explicit purpose of
distributing labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].
In this document, we try to use the acronym "LDP" to refer
specifically to the protocol defined in [MPLS-LDP]; when speaking of
label distribution protocols in general, we try to avoid the acronym.
2.7. Downstream vs. Downstream-on-Demand 2.7. Downstream vs. Downstream-on-Demand
The MPLS architecture allows an LSR to explicitly request, from its The MPLS architecture allows an LSR to explicitly request, from its
next hop for a particular FEC, a label binding for that FEC. This is next hop for a particular FEC, a label binding for that FEC. This is
known as "downstream-on-demand" label distribution. known as "downstream-on-demand" label distribution.
The MPLS architecture also allows an LSR to distribute bindings to The MPLS architecture also allows an LSR to distribute bindings to
LSRs that have not explicitly requested them. This is known as LSRs that have not explicitly requested them. This is known as
"downstream" label distribution. "downstream" label distribution.
Both of these label distribution techniques may be used in the same Both of these label distribution techniques may be used in the same
network at the same time. However, on any given LDP adjacency, the network at the same time. However, on any given label distribution
upstream LSR and the downstream LSR must agree on which technique is adjacency, the upstream LSR and the downstream LSR must agree on
to be used. which technique is to be used.
2.8. Label Retention Mode 2.8. Label Retention Mode
An LSR Ru may receive (or have received) a label binding for a An LSR Ru may receive (or have received) a label binding for a
particular FEC from an LSR Rd, even though Rd is not Ru's next hop particular FEC from an LSR Rd, even though Rd is not Ru's next hop
(or is no longer Ru's next hop) for that FEC. (or is no longer Ru's next hop) for that FEC.
Ru then has the choice of whether to keep track of such bindings, or Ru then has the choice of whether to keep track of such bindings, or
whether to discard such bindings. If Ru keeps track of such whether to discard such bindings. If Ru keeps track of such
bindings, then it may immediately begin using the binding again if Rd bindings, then it may immediately begin using the binding again if Rd
skipping to change at page 13, line 34 skipping to change at page 13, line 39
changes, but conservative label retention mode though requires an LSR changes, but conservative label retention mode though requires an LSR
to maintain many fewer labels. to maintain many fewer labels.
2.9. The Label Stack 2.9. The Label Stack
So far, we have spoken as if a labeled packet carries only a single So far, we have spoken as if a labeled packet carries only a single
label. As we shall see, it is useful to have a more general model in label. As we shall see, it is useful to have a more general model in
which a labeled packet carries a number of labels, organized as a which a labeled packet carries a number of labels, organized as a
last-in, first-out stack. We refer to this as a "label stack". last-in, first-out stack. We refer to this as a "label stack".
IN MPLS, EVERY FORWARDING DECISION IS BASED EXCLUSIVELY ON THE LABEL
AT THE TOP OF THE STACK.
Although, as we shall see, MPLS supports a hierarchy, the processing Although, as we shall see, MPLS supports a hierarchy, the processing
of a labeled packet is completely independent of the level of of a labeled packet is completely independent of the level of
hierarchy. The processing is always based on the top label, without hierarchy. The processing is always based on the top label, without
regard for the possibility that some number of other labels may have regard for the possibility that some number of other labels may have
been "above it" in the past, or that some number of other labels may been "above it" in the past, or that some number of other labels may
be below it at present. be below it at present.
An unlabeled packet can be thought of as a packet whose label stack An unlabeled packet can be thought of as a packet whose label stack
is empty (i.e., whose label stack has depth 0). is empty (i.e., whose label stack has depth 0).
skipping to change at page 15, line 7 skipping to change at page 15, line 7
may be the native IP packet. may be the native IP packet.
This implies that in some cases the LSR may need to operate on the IP This implies that in some cases the LSR may need to operate on the IP
header in order to forward the packet. header in order to forward the packet.
If the packet's "next hop" is the current LSR, then the label stack If the packet's "next hop" is the current LSR, then the label stack
operation MUST be to "pop the stack". operation MUST be to "pop the stack".
2.11. Incoming Label Map (ILM) 2.11. Incoming Label Map (ILM)
The "Incoming Label Map" (ILM) is a mapping from incoming labels to The "Incoming Label Map" (ILM) maps each incoming label to a set of
NHLFEs. It is used when forwarding packets that arrive as labeled NHLFEs. It is used when forwarding packets that arrive as labeled
packets. packets.
If the ILM maps a particular label to a set of NHLFEs that contains
more than one element, exactly one element of the set must be chosen
before the packet is forwarded. The procedures for choosing an
element from the set are beyond the scope of this document. Having
the ILM map a label to a set containing more than one NHLFE may be
useful if, e.g., it is desired to do load balancing over multiple
equal-cost paths.
2.12. FEC-to-NHLFE Map (FTN) 2.12. FEC-to-NHLFE Map (FTN)
The "FEC-to-NHLFE" (FTN) is a mapping from FECs to NHLFEs. It is used The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used
when forwarding packets that arrive unlabeled, but which are to be when forwarding packets that arrive unlabeled, but which are to be
labeled before being forwarded. labeled before being forwarded.
If the FTN maps a particular label to a set of NHLFEs that contains
more than one element, exactly one element of the set must be chosen
before the packet is forwarded. The procedures for choosing an
element from the set are beyond the scope of this document. Having
the FTN map a label to a set containing more than one NHLFE may be
useful if, e.g., it is desired to do load balancing over multiple
equal-cost paths.
2.13. Label Swapping 2.13. Label Swapping
Label swapping is the use of the following procedures to forward a Label swapping is the use of the following procedures to forward a
packet. packet.
In order to forward a labeled packet, a LSR examines the label at the In order to forward a labeled packet, a LSR examines the label at the
top of the label stack. It uses the ILM to map this label to an top of the label stack. It uses the ILM to map this label to an
NHLFE. Using the information in the NHLFE, it determines where to NHLFE. Using the information in the NHLFE, it determines where to
forward the packet, and performs an operation on the packet's label forward the packet, and performs an operation on the packet's label
stack. It then encodes the new label stack into the packet, and stack. It then encodes the new label stack into the packet, and
skipping to change at page 15, line 44 skipping to change at page 16, line 13
be illegal in this case.) It then encodes the new label stack into be illegal in this case.) It then encodes the new label stack into
the packet, and forwards the result. the packet, and forwards the result.
IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE NEXT IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE NEXT
HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES BE HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES BE
DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE. DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE.
2.14. Scope and Uniqueness of Labels 2.14. Scope and Uniqueness of Labels
A given LSR Rd may bind label L1 to FEC F, and distribute that A given LSR Rd may bind label L1 to FEC F, and distribute that
binding to LDP peer Ru1. Rd may also bind label L2 to FEC F, and binding to label distribution peer Ru1. Rd may also bind label L2 to
distribute that binding to LDP peer Ru2. Whether or not L1 == L2 is FEC F, and distribute that binding to label distribution peer Ru2.
not determined by the architecture; this is a local matter. Whether or not L1 == L2 is not determined by the architecture; this
is a local matter.
A given LSR Rd may bind label L to FEC F1, and distribute that A given LSR Rd may bind label L to FEC F1, and distribute that
binding to LDP peer Ru1. Rd may also bind label L to FEC F2, and binding to label distribution peer Ru1. Rd may also bind label L to
distribute that binding to LDP peer Ru2. IF (AND ONLY IF) RD CAN FEC F2, and distribute that binding to label distribution peer Ru2.
TELL, WHEN IT RECEIVES A PACKET WHOSE TOP LABEL IS L, WHETHER THE IF (AND ONLY IF) RD CAN TELL, WHEN IT RECEIVES A PACKET WHOSE TOP
LABEL WAS PUT THERE BY RU1 OR BY RU2, THEN THE ARCHITECTURE DOES NOT LABEL IS L, WHETHER THE LABEL WAS PUT THERE BY RU1 OR BY RU2, THEN
REQUIRE THAT F1 == F2. In such cases, we may say that Rd is using a THE ARCHITECTURE DOES NOT REQUIRE THAT F1 == F2. In such cases, we
different "label space" for the labels it distributes to Ru1 than for may say that Rd is using a different "label space" for the labels it
the labels it distributes to Ru2. distributes to Ru1 than for the labels it distributes to Ru2.
In general, Rd can only tell whether it was Ru1 or Ru2 that put the In general, Rd can only tell whether it was Ru1 or Ru2 that put the
particular label value L at the top of the label stack if the particular label value L at the top of the label stack if the
following conditions hold: following conditions hold:
- Ru1 and Ru2 are the only LDP peers to which Rd distributed a - Ru1 and Ru2 are the only label distribution peers to which Rd
binding of label value L, and distributed a binding of label value L, and
- Ru1 and Ru2 are each directly connected to Rd via a point-to- - Ru1 and Ru2 are each directly connected to Rd via a point-to-
point interface. point interface.
When these conditions hold, an LSR may use labels that have "per When these conditions hold, an LSR may use labels that have "per
interface" scope, i.e., which are only unique per interface. We may interface" scope, i.e., which are only unique per interface. We may
say that the LSR is using a "per-interface label space". When these say that the LSR is using a "per-interface label space". When these
conditions do not hold, the labels must be unique over the LSR which conditions do not hold, the labels must be unique over the LSR which
has assigned them, and we may say that the LSR is using a "per- has assigned them, and we may say that the LSR is using a "per-
platform label space." platform label space."
skipping to change at page 19, line 47 skipping to change at page 20, line 15
However, some hardware switching engines may not be able to pop the However, some hardware switching engines may not be able to pop the
label stack, so this cannot be universally required. There may also label stack, so this cannot be universally required. There may also
be some situations in which penultimate hop popping is not desirable. be some situations in which penultimate hop popping is not desirable.
Therefore the penultimate node pops the label stack only if this is Therefore the penultimate node pops the label stack only if this is
specifically requested by the egress node, OR if the next node in the specifically requested by the egress node, OR if the next node in the
LSP does not support MPLS. (If the next node in the LSP does support LSP does not support MPLS. (If the next node in the LSP does support
MPLS, but does not make such a request, the penultimate node has no MPLS, but does not make such a request, the penultimate node has no
way of knowing that it in fact is the penultimate node.) way of knowing that it in fact is the penultimate node.)
An LSR which is capable of popping the label stack at all MUST do An LSR which is capable of popping the label stack at all MUST do
penultimate hop popping when so requested by its downstream LDP peer. penultimate hop popping when so requested by its downstream label
distribution peer.
Initial LDP negotiations MUST allow each LSR to determine whether its Initial label distribution protocol negotiations MUST allow each LSR
neighboring LSRS are capable of popping the label stack. A LSR MUST to determine whether its neighboring LSRS are capable of popping the
NOT request an LDP peer to pop the label stack unless it is capable label stack. A LSR MUST NOT request a label distribution peer to pop
of doing so. the label stack unless it is capable of doing so.
It may be asked whether the egress node can always interpret the top It may be asked whether the egress node can always interpret the top
label of a received packet properly if penultimate hop popping is label of a received packet properly if penultimate hop popping is
used. As long as the uniqueness and scoping rules of section 2.14 used. As long as the uniqueness and scoping rules of section 2.14
are obeyed, it is always possible to interpret the top label of a are obeyed, it is always possible to interpret the top label of a
received packet unambiguously. received packet unambiguously.
2.17. LSP Next Hop 2.17. LSP Next Hop
The LSP Next Hop for a particular labeled packet in a particular LSR The LSP Next Hop for a particular labeled packet in a particular LSR
skipping to change at page 21, line 14 skipping to change at page 21, line 24
2.19. LSP Control: Ordered versus Independent 2.19. LSP Control: Ordered versus Independent
Some FECs correspond to address prefixes which are distributed via a Some FECs correspond to address prefixes which are distributed via a
dynamic routing algorithm. The setup of the LSPs for these FECs can dynamic routing algorithm. The setup of the LSPs for these FECs can
be done in one of two ways: Independent LSP Control or Ordered LSP be done in one of two ways: Independent LSP Control or Ordered LSP
Control. Control.
In Independent LSP Control, each LSR, upon noting that it recognizes In Independent LSP Control, each LSR, upon noting that it recognizes
a particular FEC, makes an independent decision to bind a label to a particular FEC, makes an independent decision to bind a label to
that FEC and to distribute that binding to its LDP peers. This that FEC and to distribute that binding to its label distribution
corresponds to the way that conventional IP datagram routing works; peers. This corresponds to the way that conventional IP datagram
each node makes an independent decision as to how to treat each routing works; each node makes an independent decision as to how to
packet, and relies on the routing algorithm to converge rapidly so as treat each packet, and relies on the routing algorithm to converge
to ensure that each datagram is correctly delivered. rapidly so as to ensure that each datagram is correctly delivered.
In Ordered LSP Control, an LSR only binds a label to a particular FEC In Ordered LSP Control, an LSR only binds a label to a particular FEC
if it is the egress LSR for that FEC, or if it has already received a if it is the egress LSR for that FEC, or if it has already received a
label binding for that FEC from its next hop for that FEC. label binding for that FEC from its next hop for that FEC.
If one wants to ensure that traffic in a particular FEC follows a If one wants to ensure that traffic in a particular FEC follows a
path with some specified set of properties (e.g., that the traffic path with some specified set of properties (e.g., that the traffic
does not traverse any node twice, that a specified amount of does not traverse any node twice, that a specified amount of
resources are available to the traffic, that the traffic follows an resources are available to the traffic, that the traffic follows an
explicitly specified path, etc.) ordered control must be used. With explicitly specified path, etc.) ordered control must be used. With
skipping to change at page 21, line 49 skipping to change at page 22, line 12
Ordered control and independent control are fully interoperable. Ordered control and independent control are fully interoperable.
However, unless all LSRs in an LSP are using ordered control, the However, unless all LSRs in an LSP are using ordered control, the
overall effect on network behavior is largely that of independent overall effect on network behavior is largely that of independent
control, since one cannot be sure that an LSP is not used until it is control, since one cannot be sure that an LSP is not used until it is
fully set up. fully set up.
This architecture allows the choice between independent control and This architecture allows the choice between independent control and
ordered control to be a local matter. Since the two methods ordered control to be a local matter. Since the two methods
interwork, a given LSR need support only one or the other. Generally interwork, a given LSR need support only one or the other. Generally
speaking, the choice of independent versus ordered control does not speaking, the choice of independent versus ordered control does not
appear to have any effect on the LDP mechanisms which need to be appear to have any effect on the label distribution mechanisms which
defined. need to be defined.
2.20. Aggregation 2.20. Aggregation
One way of partitioning traffic into FECs is to create a separate FEC One way of partitioning traffic into FECs is to create a separate FEC
for each address prefix which appears in the routing table. However, for each address prefix which appears in the routing table. However,
within a particular MPLS domain, this may result in a set of FECs within a particular MPLS domain, this may result in a set of FECs
such that all traffic in all those FECs follows the same route. For such that all traffic in all those FECs follows the same route. For
example, a set of distinct address prefixes might all have the same example, a set of distinct address prefixes might all have the same
egress node, and label swapping might be used only to get the the egress node, and label swapping might be used only to get the the
traffic to the egress node. In this case, within the MPLS domain, traffic to the egress node. In this case, within the MPLS domain,
the union of those FECs is itself a FEC. This creates a choice: the union of those FECs is itself a FEC. This creates a choice:
should a distinct label be bound to each component FEC, or should a should a distinct label be bound to each component FEC, or should a
single label be bound to the union, and that label applied to all single label be bound to the union, and that label applied to all
traffic in the union? traffic in the union?
The procedure of binding a single label to a union of FECs which is The procedure of binding a single label to a union of FECs which is
itself a FEC (within some domain), and of applying that label to all itself a FEC (within some domain), and of applying that label to all
traffic in the union, is known as "aggregation". The MPLS traffic in the union, is known as "aggregation". The MPLS
architecture allows aggregation. Aggregation may reduce the number architecture allows aggregation. Aggregation may reduce the number
of labels which are needed to handle a particular set of packets, and of labels which are needed to handle a particular set of packets, and
may also reduce the amount of LDP control traffic needed. may also reduce the amount of label distribution control traffic
needed.
Given a set of FECs which are "aggregatable" into a single FEC, it is Given a set of FECs which are "aggregatable" into a single FEC, it is
possible to (a) aggregate them into a single FEC, (b) aggregate them possible to (a) aggregate them into a single FEC, (b) aggregate them
into a set of FECs, or (c) not aggregate them at all. Thus we can into a set of FECs, or (c) not aggregate them at all. Thus we can
speak of the "granularity" of aggregation, with (a) being the speak of the "granularity" of aggregation, with (a) being the
"coarsest granularity", and (c) being the "finest granularity". "coarsest granularity", and (c) being the "finest granularity".
When order control is used, each LSR should adopt, for a given set of When order control is used, each LSR should adopt, for a given set of
FECs, the granularity used by its next hop for those FECs. FECs, the granularity used by its next hop for those FECs.
skipping to change at page 27, line 30 skipping to change at page 27, line 41
LSRs". LSRs".
There are three obvious ways to encode labels in the ATM cell header There are three obvious ways to encode labels in the ATM cell header
(presuming the use of AAL5): (presuming the use of AAL5):
1. SVC Encoding 1. SVC Encoding
Use the VPI/VCI field to encode the label which is at the top Use the VPI/VCI field to encode the label which is at the top
of the label stack. This technique can be used in any network. of the label stack. This technique can be used in any network.
With this encoding technique, each LSP is realized as an ATM With this encoding technique, each LSP is realized as an ATM
SVC, and the LDP becomes the ATM "signaling" protocol. With SVC, and the label distribution protocol becomes the ATM
this encoding technique, the ATM-LSRs cannot perform "push" or "signaling" protocol. With this encoding technique, the ATM-
"pop" operations on the label stack. LSRs cannot perform "push" or "pop" operations on the label
stack.
2. SVP Encoding 2. SVP Encoding
Use the VPI field to encode the label which is at the top of Use the VPI field to encode the label which is at the top of
the label stack, and the VCI field to encode the second label the label stack, and the VCI field to encode the second label
on the stack, if one is present. This technique some advantages on the stack, if one is present. This technique some advantages
over the previous one, in that it permits the use of ATM "VP- over the previous one, in that it permits the use of ATM "VP-
switching". That is, the LSPs are realized as ATM SVPs, with switching". That is, the LSPs are realized as ATM SVPs, with
LDP serving as the ATM signaling protocol. the label distribution protocol serving as the ATM signaling
protocol.
However, this technique cannot always be used. If the network However, this technique cannot always be used. If the network
includes an ATM Virtual Path through a non-MPLS ATM network, includes an ATM Virtual Path through a non-MPLS ATM network,
then the VPI field is not necessarily available for use by then the VPI field is not necessarily available for use by
MPLS. MPLS.
When this encoding technique is used, the ATM-LSR at the egress When this encoding technique is used, the ATM-LSR at the egress
of the VP effectively does a "pop" operation. of the VP effectively does a "pop" operation.
3. SVP Multipoint Encoding 3. SVP Multipoint Encoding
skipping to change at page 29, line 44 skipping to change at page 30, line 9
more detail in the next section. more detail in the next section.
If a particular LSR cannot perform label merging, then if two packets If a particular LSR cannot perform label merging, then if two packets
in the same FEC arrive with different incoming labels, they must be in the same FEC arrive with different incoming labels, they must be
forwarded with different outgoing labels. With label merging, the forwarded with different outgoing labels. With label merging, the
number of outgoing labels per FEC need only be 1; without label number of outgoing labels per FEC need only be 1; without label
merging, the number of outgoing labels per FEC could be as large as merging, the number of outgoing labels per FEC could be as large as
the number of nodes in the network. the number of nodes in the network.
With label merging, the number of incoming labels per FEC that a With label merging, the number of incoming labels per FEC that a
particular LSR needs is never be larger than the number of LDP particular LSR needs is never be larger than the number of label
adjacencies. Without label merging, the number of incoming labels distribution adjacencies. Without label merging, the number of
per FEC that a particular LSR needs is as large as the number of incoming labels per FEC that a particular LSR needs is as large as
upstream nodes which forward traffic in the FEC to the LSR in the number of upstream nodes which forward traffic in the FEC to the
question. In fact, it is difficult for an LSR to even determine how LSR in question. In fact, it is difficult for an LSR to even
many such incoming labels it must support for a particular FEC. determine how many such incoming labels it must support for a
particular FEC.
The MPLS architecture accommodates both merging and non-merging LSRs, The MPLS architecture accommodates both merging and non-merging LSRs,
but allows for the fact that there may be LSRs which do not support but allows for the fact that there may be LSRs which do not support
label merging. This leads to the issue of ensuring correct label merging. This leads to the issue of ensuring correct
interoperation between merging LSRs and non-merging LSRs. The issue interoperation between merging LSRs and non-merging LSRs. The issue
is somewhat different in the case of datagram media versus the case is somewhat different in the case of datagram media versus the case
of ATM. The different media types will therefore be discussed of ATM. The different media types will therefore be discussed
separately. separately.
2.26.1. Non-merging LSRs 2.26.1. Non-merging LSRs
The MPLS forwarding procedures is very similar to the forwarding The MPLS forwarding procedures is very similar to the forwarding
procedures used by such technologies as ATM and Frame Relay. That is, procedures used by such technologies as ATM and Frame Relay. That is,
a unit of data arrives, a label (VPI/VCI or DLCI) is looked up in a a unit of data arrives, a label (VPI/VCI or DLCI) is looked up in a
"cross-connect table", on the basis of that lookup an output port is "cross-connect table", on the basis of that lookup an output port is
chosen, and the label value is rewritten. In fact, it is possible to chosen, and the label value is rewritten. In fact, it is possible to
use such technologies for MPLS forwarding; an LDP can be used as the use such technologies for MPLS forwarding; a label distribution
"signalling protocol" for setting up the cross-connect tables. protocol can be used as the "signalling protocol" for setting up the
cross-connect tables.
Unfortunately, these technologies do not necessarily support the Unfortunately, these technologies do not necessarily support the
label merging capability. In ATM, if one attempts to perform label label merging capability. In ATM, if one attempts to perform label
merging, the result may be the interleaving of cells from various merging, the result may be the interleaving of cells from various
packets. If cells from different packets get interleaved, it is packets. If cells from different packets get interleaved, it is
impossible to reassemble the packets. Some Frame Relay switches use impossible to reassemble the packets. Some Frame Relay switches use
cell switching on their backplanes. These switches may also be cell switching on their backplanes. These switches may also be
incapable of supporting label merging, for the same reason -- cells incapable of supporting label merging, for the same reason -- cells
of different packets may get interleaved, and there is then no way to of different packets may get interleaved, and there is then no way to
reassemble the packets. reassemble the packets.
skipping to change at page 34, line 40 skipping to change at page 35, line 8
to R3. Then it pushes on a new label. This level 2 label has a value to R3. Then it pushes on a new label. This level 2 label has a value
which is meaningful to R21. Switching is done on the level 2 label by which is meaningful to R21. Switching is done on the level 2 label by
R21, R22, R23. R23, which is the penultimate hop in the R2-R3 tunnel, R21, R22, R23. R23, which is the penultimate hop in the R2-R3 tunnel,
pops the label stack before forwarding the packet to R3. When R3 sees pops the label stack before forwarding the packet to R3. When R3 sees
packet P, P has only a level 1 label, having now exited the tunnel. packet P, P has only a level 1 label, having now exited the tunnel.
Since R3 is the penultimate hop in P's level 1 LSP, it pops the label Since R3 is the penultimate hop in P's level 1 LSP, it pops the label
stack, and R4 receives P unlabeled. stack, and R4 receives P unlabeled.
The label stack mechanism allows LSP tunneling to nest to any depth. The label stack mechanism allows LSP tunneling to nest to any depth.
2.27.5. LDP Peering and Hierarchy 2.27.5. Label Distribution Peering and Hierarchy
Suppose that packet P travels along a Level 1 LSP <R1, R2, R3, R4>, Suppose that packet P travels along a Level 1 LSP <R1, R2, R3, R4>,
and when going from R2 to R3 travels along a Level 2 LSP <R2, R21, and when going from R2 to R3 travels along a Level 2 LSP <R2, R21,
R22, R3>. From the perspective of the Level 2 LSP, R2's LDP peer is R22, R3>. From the perspective of the Level 2 LSP, R2's label
R21. From the perspective of the Level 1 LSP, R2's LDP peers are R1 distribution peer is R21. From the perspective of the Level 1 LSP,
and R3. One can have LDP peers at each layer of hierarchy. We will R2's label distribution peers are R1 and R3. One can have label
see in sections 3.6 and 3.7 some ways to make use of this hierarchy. distribution peers at each layer of hierarchy. We will see in
Note that in this example, R2 and R21 must be IGP neighbors, but R2 sections 3.6 and 3.7 some ways to make use of this hierarchy. Note
and R3 need not be. that in this example, R2 and R21 must be IGP neighbors, but R2 and R3
need not be.
When two LSRs are IGP neighbors, we will refer to them as "Local LDP When two LSRs are IGP neighbors, we will refer to them as "local
Peers". When two LSRs may be LDP peers, but are not IGP neighbors, label distribution peers". When two LSRs may be label distribution
we will refer to them as "Remote LDP Peers". In the above example, peers, but are not IGP neighbors, we will refer to them as "remote
R2 and R21 are local LDP peers, but R2 and R3 are remote LDP peers. label distribution peers". In the above example, R2 and R21 are
local label distribution peers, but R2 and R3 are remote label
distribution peers.
The MPLS architecture supports two ways to distribute labels at The MPLS architecture supports two ways to distribute labels at
different layers of the hierarchy: Explicit Peering and Implicit different layers of the hierarchy: Explicit Peering and Implicit
Peering. Peering.
One performs label Distribution with one's Local LDP Peers by opening One performs label distribution with one's local label distribution
LDP connections to them. One can perform label Distribution with peer by sending label distribution protocol messages which are
one's Remote LDP Peers in one of two ways: addressed to the peer. One can perform label distribution with one's
remote label distribution peers in one of two ways:
1. Explicit Peering 1. Explicit Peering
In explicit peering, one sets up LDP connections between Remote In explicit peering, one distributes labels to a peer by
LDP Peers, exactly as one would do for Local LDP Peers. This sending label distribution protocol messages which are
technique is most useful when the number of Remote LDP Peers is addressed to the peer, exactly as one would do for local label
small, or the number of higher level label bindings is large, distribution peers. This technique is most useful when the
or the Remote LDP Peers are in distinct routing areas or number of remote label distribution peers is small, or the
number of higher level label bindings is large, or the remote
label distribution peers are in distinct routing areas or
domains. Of course, one needs to know which labels to domains. Of course, one needs to know which labels to
distribute to which peers; this is addressed in section 3.1.2. distribute to which peers; this is addressed in section 3.1.2.
Examples of the use of explicit peering is found in sections Examples of the use of explicit peering is found in sections
3.2.1 and 3.6. 3.2.1 and 3.6.
2. Implicit Peering 2. Implicit Peering
In Implicit Peering, one does not have LDP connections to one's In Implicit Peering, one does not send label distribution
remote LDP peers, but only to one's local LDP peers. To protocol messages which are addressed to one's peer. Rather,
distribute higher level labels to ones remote LDP peers, one to distribute higher level labels to ones remote label
encodes the higher level labels as an attribute of the lower distribution peers, one encodes a higher level label as an
level labels, and distributes the lower level label, along with attribute of a lower level label, and then distributes the
this attribute, to the local LDP peers. The local LDP peers lower level label, along with this attribute, to one's local
then propagate the information to their peers. This process label distribution peers. The local label distribution peers
continues till the information reaches remote LDP peers. Note then propagate the information to their local label
that the intermediary nodes may also be remote LDP peers. distribution peers. This process continues till the information
reaches the remote peer.
This technique is most useful when the number of Remote LDP This technique is most useful when the number of remote label
Peers is large. Implicit peering does not require a n-square distribution peers is large. Implicit peering does not require
peering mesh to distribute labels to the remote LDP peers an n-square peering mesh to distribute labels to the remote
because the information is piggybacked through the local LDP label distribution peers because the information is piggybacked
peering. However, implicit peering requires the intermediate through the local label distribution peering. However,
nodes to store information that they might not be directly implicit peering requires the intermediate nodes to store
interested in. information that they might not be directly interested in.
An example of the use of implicit peering is found in section An example of the use of implicit peering is found in section
3.3. 3.3.
2.28. LDP Transport 2.28. Label Distribution Protocol Transport
LDP is used between nodes in an MPLS network to establish and A label distribution protocol is used between nodes in an MPLS
maintain the label bindings. In order for LDP to operate correctly, network to establish and maintain the label bindings. In order for
LDP information needs to be transmitted reliably, and the LDP MPLS to operate correctly, label distribution information needs to be
messages pertaining to a particular FEC need to be transmitted in transmitted reliably, and the label distribution protocol messages
sequence. Flow control is also required, as is the capability to pertaining to a particular FEC need to be transmitted in sequence.
carry multiple LDP messages in a single datagram. Flow control is also desirable, as is the capability to carry
multiple label messages in a single datagram.
These goals will be met by using TCP as the underlying transport for One way to meet these goals is to use TCP as the underlying
LDP. transport, as is done in [MPLS-LDP] and [MPLS-BGP].
(The use of multicast techniques to distribute label bindings is for 2.29. Why More than one Label Distribution Protocol?
further study.)
2.29. Multicast This architecture does not establish hard and fast rules for choosing
which label distribution protocol to use in which circumstances.
However, it is possible to point out some of the considerations.
2.29.1. BGP and LDP
In many scenarios, it is desirable to bind labels to FECs which can
be identified with routes to address prefixes (see section 3.1). If
there is a standard, widely deployed routing algorithm which
distributes those routes, it can be argued that label distribution is
best achieved by piggybacking the label distribution on the
distribution of the routes themselves.
For example, BGP distributes such routes, and if a BGP speaker needs
to also distribute labels to its BGP peers, using BGP to do the label
distribution (see [MPLS-BGP]) has a number of advantages. In
particular, it permits BGP route reflectors to distribute labels,
thus providing a significant scalability advantage over using LDP to
distribute labels between BGP peers.
2.29.2. Labels for RSVP Flowspecs
When RSVP is used to set up resource reservations for particular
flows, it can be desirable to label the packets in those flows, so
that the RSVP filterspec does not need to be applied at each hop. It
can be argued that having RSVP distribute the labels as part of its
path/reservation setup process is the most efficient method of
distributing labels for this purpose.
2.29.3. Labels for Explicitly Routed LSPs
In some applications of MPLS, particularly those related to traffic
engineering, it is desirable to set up an explicitly routed path,
from ingress to egress. It is also desirable to apply resource
reservations along that path.
One can imagine two approaches to this:
- Start with an existing protocol that is used for setting up
resource reservations, and extend it to support explicit routing
and label distribution.
- Start with an existing protocol that is used for label
distribution, and extend it to support explicit routing and
resource reservations.
The first approach has given rise to the protocol specified in
[MPLS-RSVP-TUNNELS], the second to the approach specified in [MPLS-
CR-LDP].
2.30. Multicast
This section is for further study This section is for further study
3. Some Applications of MPLS 3. Some Applications of MPLS
3.1. MPLS and Hop by Hop Routed Traffic 3.1. MPLS and Hop by Hop Routed Traffic
A number of uses of MPLS require that packets with a certain label be A number of uses of MPLS require that packets with a certain label be
forwarded along the same hop-by-hop routed path that would be used forwarded along the same hop-by-hop routed path that would be used
for forwarding a packet with a specified address in its network layer for forwarding a packet with a specified address in its network layer
skipping to change at page 37, line 7 skipping to change at page 38, line 32
for P's destination address. That is, the packets in a given FEC are for P's destination address. That is, the packets in a given FEC are
just those packets which match a given address prefix in R's routing just those packets which match a given address prefix in R's routing
table. In this case, a FEC can be identified with an address prefix. table. In this case, a FEC can be identified with an address prefix.
Note that a packet P may be assigned to FEC F, and FEC F may be Note that a packet P may be assigned to FEC F, and FEC F may be
identified with address prefix X, even if P's destination address identified with address prefix X, even if P's destination address
does not match X. does not match X.
3.1.2. Distributing Labels for Address Prefixes 3.1.2. Distributing Labels for Address Prefixes
3.1.2.1. LDP Peers for a Particular Address Prefix 3.1.2.1. Label Distribution Peers for an Address Prefix
LSRs R1 and R2 are considered to be LDP Peers for address prefix X if LSRs R1 and R2 are considered to be label distribution peers for
and only if one of the following conditions holds: address prefix X if and only if one of the following conditions
holds:
1. R1's route to X is a route which it learned about via a 1. R1's route to X is a route which it learned about via a
particular instance of a particular IGP, and R2 is a neighbor particular instance of a particular IGP, and R2 is a neighbor
of R1 in that instance of that IGP of R1 in that instance of that IGP
2. R1's route to X is a route which it learned about by some 2. R1's route to X is a route which it learned about by some
instance of routing algorithm A1, and that route is instance of routing algorithm A1, and that route is
redistributed into an instance of routing algorithm A2, and R2 redistributed into an instance of routing algorithm A2, and R2
is a neighbor of R1 in that instance of A2 is a neighbor of R1 in that instance of A2
3. R1 is the receive endpoint of an LSP Tunnel that is within 3. R1 is the receive endpoint of an LSP Tunnel that is within
another LSP, and R2 is a transmit endpoint of that tunnel, and another LSP, and R2 is a transmit endpoint of that tunnel, and
R1 and R2 are participants in a common instance of an IGP, and R1 and R2 are participants in a common instance of an IGP, and
are in the same IGP area (if the IGP in question has areas), are in the same IGP area (if the IGP in question has areas),
and R1's route to X was learned via that IGP instance, or is and R1's route to X was learned via that IGP instance, or is
redistributed by R1 into that IGP instance redistributed by R1 into that IGP instance
4. R1's route to X is a route which it learned about via BGP, and 4. R1's route to X is a route which it learned about via BGP, and
R2 is a BGP peer of R1 R2 is a BGP peer of R1
skipping to change at page 37, line 32 skipping to change at page 39, line 15
another LSP, and R2 is a transmit endpoint of that tunnel, and another LSP, and R2 is a transmit endpoint of that tunnel, and
R1 and R2 are participants in a common instance of an IGP, and R1 and R2 are participants in a common instance of an IGP, and
are in the same IGP area (if the IGP in question has areas), are in the same IGP area (if the IGP in question has areas),
and R1's route to X was learned via that IGP instance, or is and R1's route to X was learned via that IGP instance, or is
redistributed by R1 into that IGP instance redistributed by R1 into that IGP instance
4. R1's route to X is a route which it learned about via BGP, and 4. R1's route to X is a route which it learned about via BGP, and
R2 is a BGP peer of R1 R2 is a BGP peer of R1
In general, these rules ensure that if the route to a particular In general, these rules ensure that if the route to a particular
address prefix is distributed via an IGP, the LDP peers for that address prefix is distributed via an IGP, the label distribution
address prefix are the IGP neighbors. If the route to a particular peers for that address prefix are the IGP neighbors. If the route to
address prefix is distributed via BGP, the LDP peers for that address a particular address prefix is distributed via BGP, the label
prefix are the BGP peers. In other cases of LSP tunneling, the distribution peers for that address prefix are the BGP peers. In
tunnel endpoints are LDP peers. other cases of LSP tunneling, the tunnel endpoints are label
distribution peers.
3.1.2.2. Distributing Labels 3.1.2.2. Distributing Labels
In order to use MPLS for the forwarding of packets according to the In order to use MPLS for the forwarding of packets according to the
hop-by-hop route corresponding to any address prefix, each LSR MUST: hop-by-hop route corresponding to any address prefix, each LSR MUST:
1. bind one or more labels to each address prefix that appears in 1. bind one or more labels to each address prefix that appears in
its routing table; its routing table;
2. for each such address prefix X, use an LDP to distribute the 2. for each such address prefix X, use a label distribution
binding of a label to X to each of its LDP Peers for X. protocol to distribute the binding of a label to X to each of
its label distribution peers for X.
There is also one circumstance in which an LSR must distribute a There is also one circumstance in which an LSR must distribute a
label binding for an address prefix, even if it is not the LSR which label binding for an address prefix, even if it is not the LSR which
bound that label to that address prefix: bound that label to that address prefix:
3. If R1 uses BGP to distribute a route to X, naming some other 3. If R1 uses BGP to distribute a route to X, naming some other
LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has
assigned label L to X, then R1 must distribute the binding assigned label L to X, then R1 must distribute the binding
between L and X to any BGP peer to which it distributes that between L and X to any BGP peer to which it distributes that
route. route.
skipping to change at page 39, line 21 skipping to change at page 41, line 5
routing table which is the longest match for Y, or routing table which is the longest match for Y, or
2. R contains in its routing tables one or more address prefixes Y 2. R contains in its routing tables one or more address prefixes Y
such that X is a proper initial substring of Y, but R's "LSP such that X is a proper initial substring of Y, but R's "LSP
previous hops" for X do not contain any such address prefixes previous hops" for X do not contain any such address prefixes
Y; that is, R is a "deaggregation point" for address prefix X. Y; that is, R is a "deaggregation point" for address prefix X.
An LSR R1 is considered to be an "LSP Proxy Egress" LSR for address An LSR R1 is considered to be an "LSP Proxy Egress" LSR for address
prefix X if and only if: prefix X if and only if:
1. R1's next hop for X is R2, and R1 and R2 are not LDP Peers with 1. R1's next hop for X is R2, and R1 and R2 are not label
respect to X (perhaps because R2 does not support MPLS), or distribution peers with respect to X (perhaps because R2 does
not support MPLS), or
2. R1 has been configured to act as an LSP Proxy Egress for X 2. R1 has been configured to act as an LSP Proxy Egress for X
The definition of LSP allows for the LSP Egress to be a node which The definition of LSP allows for the LSP Egress to be a node which
does not support MPLS; in this case the penultimate node in the LSP does not support MPLS; in this case the penultimate node in the LSP
is the Proxy Egress. is the Proxy Egress.
3.1.5. The Implicit NULL Label 3.1.5. The Implicit NULL Label
The Implicit NULL label is a label with special semantics which an The Implicit NULL label is a label with special semantics which an
skipping to change at page 39, line 46 skipping to change at page 41, line 31
address prefix, then instead of replacing the value of the label on address prefix, then instead of replacing the value of the label on
top of the label stack, Ru pops the label stack, and then forwards top of the label stack, Ru pops the label stack, and then forwards
the resulting packet to Rd. the resulting packet to Rd.
LSR Rd distributes a binding between Implicit NULL and an address LSR Rd distributes a binding between Implicit NULL and an address
prefix X to LSR Ru if and only if: prefix X to LSR Ru if and only if:
1. the rules of Section 3.1.2 indicate that Rd distributes to Ru a 1. the rules of Section 3.1.2 indicate that Rd distributes to Ru a
label binding for X, and label binding for X, and
2. when the LDP connection between Ru and Rd was opened, Ru 2. Rd knows that Ru can support the Implicit NULL label (i.e.,
indicated that it could support the Implicit NULL label (i.e.,
that it can pop the label stack), and that it can pop the label stack), and
3. Rd is an LSP Egress (not proxy egress) for X. 3. Rd is an LSP Egress (not proxy egress) for X.
This causes the penultimate LSR on a LSP to pop the label stack. This This causes the penultimate LSR on a LSP to pop the label stack. This
is quite appropriate; if the LSP Egress is an MPLS Egress for X, then is quite appropriate; if the LSP Egress is an MPLS Egress for X, then
if the penultimate LSR does not pop the label stack, the LSP Egress if the penultimate LSR does not pop the label stack, the LSP Egress
will need to look up the label, pop the label stack, and then look up will need to look up the label, pop the label stack, and then look up
the next label (or look up the L3 address, if no more labels are the next label (or look up the L3 address, if no more labels are
present). By having the penultimate LSR pop the label stack, the LSP present). By having the penultimate LSR pop the label stack, the LSP
Egress is saved the work of having to look up two labels in order to Egress is saved the work of having to look up two labels in order to
make its forwarding decision. make its forwarding decision.
skipping to change at page 41, line 9 skipping to change at page 42, line 36
- If the network is running a link state routing algorithm, and all - If the network is running a link state routing algorithm, and all
nodes in the area support MPLS, then the routing algorithm nodes in the area support MPLS, then the routing algorithm
provides Ri with enough information to determine the routers provides Ri with enough information to determine the routers
through which packets in that FEC must leave the routing domain through which packets in that FEC must leave the routing domain
or area. or area.
- If the network is running BGP, Ri may be able to determine that - If the network is running BGP, Ri may be able to determine that
the packets in a particular FEC must leave the network via some the packets in a particular FEC must leave the network via some
particular router which is the "BGP Next Hop" for that FEC. particular router which is the "BGP Next Hop" for that FEC.
- It is possible to use the LDP to pass information about which - It is possible to use the label distribution protocol to pass
address prefixes are "attached" to which egress LSRs. This information about which address prefixes are "attached" to which
method has the advantage of not depending on the presence of link egress LSRs. This method has the advantage of not depending on
state routing. the presence of link state routing.
If egress-targeted label assignment is used, the number of labels If egress-targeted label assignment is used, the number of labels
that need to be supported throughout the network may be greatly that need to be supported throughout the network may be greatly
reduced. This may be significant if one is using legacy switching reduced. This may be significant if one is using legacy switching
hardware to do MPLS, and the switching hardware can support only a hardware to do MPLS, and the switching hardware can support only a
limited number of labels. limited number of labels.
One possible approach would be to configure the network to use One possible approach would be to configure the network to use
egress-targeted label assignment by default, but to configure egress-targeted label assignment by default, but to configure
particular LSRs to NOT use egress-targeted label assignment for one particular LSRs to NOT use egress-targeted label assignment for one
skipping to change at page 42, line 43 skipping to change at page 44, line 23
3. A means of ensuring that packets sent into the Tunnel will not 3. A means of ensuring that packets sent into the Tunnel will not
loop from the receive endpoint back to the transmit endpoint. loop from the receive endpoint back to the transmit endpoint.
If the transmit endpoint of the tunnel wishes to put a labeled packet If the transmit endpoint of the tunnel wishes to put a labeled packet
into the tunnel, it must first replace the label value at the top of into the tunnel, it must first replace the label value at the top of
the stack with a label value that was distributed to it by the the stack with a label value that was distributed to it by the
tunnel's receive endpoint. Then it must push on the label which tunnel's receive endpoint. Then it must push on the label which
corresponds to the tunnel itself, as distributed to it by the next corresponds to the tunnel itself, as distributed to it by the next
hop along the tunnel. To allow this, the tunnel endpoints should be hop along the tunnel. To allow this, the tunnel endpoints should be
explicit LDP peers. The label bindings they need to exchange are of explicit label distribution peers. The label bindings they need to
no interest to the LSRs along the tunnel. exchange are of no interest to the LSRs along the tunnel.
3.3. Label Stacks and Implicit Peering 3.3. Label Stacks and Implicit Peering
Suppose a particular LSR Re is an LSP proxy egress for 10 address Suppose a particular LSR Re is an LSP proxy egress for 10 address
prefixes, and it reaches each address prefix through a distinct prefixes, and it reaches each address prefix through a distinct
interface. interface.
One could assign a single label to all 10 address prefixes. Then Re One could assign a single label to all 10 address prefixes. Then Re
is an LSP egress for all 10 address prefixes. This ensures that is an LSP egress for all 10 address prefixes. This ensures that
packets for all 10 address prefixes get delivered to Re. However, Re packets for all 10 address prefixes get delivered to Re. However, Re
skipping to change at page 43, line 38 skipping to change at page 45, line 13
following rules: following rules:
- When LSR Ru initially labels a hitherto unlabeled packet, if the - When LSR Ru initially labels a hitherto unlabeled packet, if the
longest match for the packet's destination address is X, and Ru's longest match for the packet's destination address is X, and Ru's
LSP next hop for X is Rd, and Rd has distributed to Ru a binding LSP next hop for X is Rd, and Rd has distributed to Ru a binding
of label L1 to X, along with a stack attribute of L2, then of label L1 to X, along with a stack attribute of L2, then
1. Ru must push L2 and then L1 onto the packet's label stack, 1. Ru must push L2 and then L1 onto the packet's label stack,
and then forward the packet to Rd; and then forward the packet to Rd;
2. When Ru distributes label bindings for X to its LDP peers, 2. When Ru distributes label bindings for X to its label
it must include L2 as the stack attribute. distribution peers, it must include L2 as the stack
attribute.
3. Whenever the stack attribute changes (possibly as a result 3. Whenever the stack attribute changes (possibly as a result
of a change in Ru's LSP next hop for X), Ru must distribute of a change in Ru's LSP next hop for X), Ru must distribute
the new stack attribute. the new stack attribute.
Note that although the label value bound to X may be different at Note that although the label value bound to X may be different at
each hop along the LSP, the stack attribute value is passed each hop along the LSP, the stack attribute value is passed
unchanged, and is set by the LSP proxy egress. unchanged, and is set by the LSP proxy egress.
Thus the LSP proxy egress for X becomes an "implicit peer" with each Thus the LSP proxy egress for X becomes an "implicit peer" with each
skipping to change at page 46, line 26 skipping to change at page 47, line 46
With these procedures, a given packet P follows a level 1 LSP all of With these procedures, a given packet P follows a level 1 LSP all of
whose members are BGP Border Routers, and between each pair of BGP whose members are BGP Border Routers, and between each pair of BGP
Border Routers in the level 1 LSP, it follows a level 2 LSP. Border Routers in the level 1 LSP, it follows a level 2 LSP.
These procedures effectively create a Hop-by-Hop Routed LSP Tunnel These procedures effectively create a Hop-by-Hop Routed LSP Tunnel
between the BGP Border Routers. between the BGP Border Routers.
Since the BGP border routers are exchanging label bindings for Since the BGP border routers are exchanging label bindings for
address prefixes that are not even known to the IGP routing, the BGP address prefixes that are not even known to the IGP routing, the BGP
routers should become explicit LDP peers with each other. routers should become explicit label distribution peers with each
other.
It is sometimes possible to create Hop-by-Hop Routed LSP Tunnels
between two BGP Border Routers, even if they are not in the same
Autonomous System. Suppose, for example, that B1 and B2 are in AS 1.
Suppose that B3 is an EBGP neighbor of B2, and is in AS2. Finally,
suppose that B2 and B3 are on some network which is common to both
Autonomous Systems (a "Demilitarized Zone"). In this case, an LSP
tunnel can be set up directly between B1 and B3 as follows:
- B3 distributes routes to B2 (using EBGP), optionally assigning
labels to address prefixes;
- B2 redistributes those routes to B1 (using IBGP), indicating that
the BGP next hop for each such route is B3. If B3 has assigned
labels to address prefixes, B2 passes these labels along,
unchanged, to B1.
- The IGP of AS1 has a host route for B3.
3.7. Other Uses of Hop-by-Hop Routed LSP Tunnels 3.7. Other Uses of Hop-by-Hop Routed LSP Tunnels
The use of Hop-by-Hop Routed LSP Tunnels is not restricted to tunnels The use of Hop-by-Hop Routed LSP Tunnels is not restricted to tunnels
between BGP Next Hops. Any situation in which one might otherwise between BGP Next Hops. Any situation in which one might otherwise
have used an encapsulation tunnel is one in which it is appropriate have used an encapsulation tunnel is one in which it is appropriate
to use a Hop-by-Hop Routed LSP Tunnel. Instead of encapsulating the to use a Hop-by-Hop Routed LSP Tunnel. Instead of encapsulating the
packet with a new header whose destination address is the address of packet with a new header whose destination address is the address of
the tunnel's receive endpoint, the label corresponding to the address the tunnel's receive endpoint, the label corresponding to the address
prefix which is the longest match for the address of the tunnel's prefix which is the longest match for the address of the tunnel's
receive endpoint is pushed on the packet's label stack. The packet receive endpoint is pushed on the packet's label stack. The packet
which is sent into the tunnel may or may not already be labeled. which is sent into the tunnel may or may not already be labeled.
If the transmit endpoint of the tunnel wishes to put a labeled packet If the transmit endpoint of the tunnel wishes to put a labeled packet
into the tunnel, it must first replace the label value at the top of into the tunnel, it must first replace the label value at the top of
the stack with a label value that was distributed to it by the the stack with a label value that was distributed to it by the
tunnel's receive endpoint. Then it must push on the label which tunnel's receive endpoint. Then it must push on the label which
corresponds to the tunnel itself, as distributed to it by the next corresponds to the tunnel itself, as distributed to it by the next
hop along the tunnel. To allow this, the tunnel endpoints should be hop along the tunnel. To allow this, the tunnel endpoints should be
explicit LDP peers. The label bindings they need to exchange are of explicit label distribution peers. The label bindings they need to
no interest to the LSRs along the tunnel. exchange are of no interest to the LSRs along the tunnel.
3.8. MPLS and Multicast 3.8. MPLS and Multicast
Multicast routing proceeds by constructing multicast trees. The tree Multicast routing proceeds by constructing multicast trees. The tree
along which a particular multicast packet must get forwarded depends along which a particular multicast packet must get forwarded depends
in general on the packet's source address and its destination in general on the packet's source address and its destination
address. Whenever a particular LSR is a node in a particular address. Whenever a particular LSR is a node in a particular
multicast tree, it binds a label to that tree. It then distributes multicast tree, it binds a label to that tree. It then distributes
that binding to its parent on the multicast tree. (If the node in that binding to its parent on the multicast tree. (If the node in
question is on a LAN, and has siblings on that LAN, it must also question is on a LAN, and has siblings on that LAN, it must also
distribute the binding to its siblings. This allows the parent to distribute the binding to its siblings. This allows the parent to
use a single label value when multicasting to all children on the use a single label value when multicasting to all children on the
LAN.) LAN.)
When a multicast labeled packet arrives, the NHLFE corresponding to When a multicast labeled packet arrives, the NHLFE corresponding to
the label indicates the set of output interfaces for that packet, as the label indicates the set of output interfaces for that packet, as
well as the outgoing label. If the same label encoding technique is well as the outgoing label. If the same label encoding technique is
used on all the outgoing interfaces, the very same packet can be sent used on all the outgoing interfaces, the very same packet can be sent
to all the children. to all the children.
4. LDP Procedures for Hop-by-Hop Routed Traffic 4. Label Distribution Procedures (Hop-by-Hop)
4.1. The Procedures for Advertising and Using labels
In this section, we consider only label bindings that are used for In this section, we consider only label bindings that are used for
traffic to be label switched along its hop-by-hop routed path. In traffic to be label switched along its hop-by-hop routed path. In
these cases, the label in question will correspond to an address these cases, the label in question will correspond to an address
prefix in the routing table. prefix in the routing table.
4.1. The Procedures for Advertising and Using labels
There are a number of different procedures that may be used to There are a number of different procedures that may be used to
distribute label bindings. Some are executed by the downstream LSR, distribute label bindings. Some are executed by the downstream LSR,
and some by the upstream LSR. and some by the upstream LSR.
The downstream LSR must perform: The downstream LSR must perform:
- The Distribution Procedure, and - The Distribution Procedure, and
- the Withdrawal Procedure. - the Withdrawal Procedure.
skipping to change at page 48, line 20 skipping to change at page 50, line 9
However, the MPLS architecture does not support all possible However, the MPLS architecture does not support all possible
combinations of all possible variants. The set of supported combinations of all possible variants. The set of supported
combinations will be described in section 4.2, where the combinations will be described in section 4.2, where the
interoperability between different combinations will also be interoperability between different combinations will also be
discussed. discussed.
4.1.1. Downstream LSR: Distribution Procedure 4.1.1. Downstream LSR: Distribution Procedure
The Distribution Procedure is used by a downstream LSR to determine The Distribution Procedure is used by a downstream LSR to determine
when it should distribute a label binding for a particular address when it should distribute a label binding for a particular address
prefix to its LDP peers. The architecture supports four different prefix to its label distribution peers. The architecture supports
distribution procedures. four different distribution procedures.
Irrespective of the particular procedure that is used, if a label Irrespective of the particular procedure that is used, if a label
binding for a particular address prefix has been distributed by a binding for a particular address prefix has been distributed by a
downstream LSR Rd to an upstream LSR Ru, and if at any time the downstream LSR Rd to an upstream LSR Ru, and if at any time the
attributes (as defined above) of that binding change, then Rd must attributes (as defined above) of that binding change, then Rd must
inform Ru of the new attributes. inform Ru of the new attributes.
If an LSR is maintaining multiple routes to a particular address If an LSR is maintaining multiple routes to a particular address
prefix, it is a local matter as to whether that LSR binds multiple prefix, it is a local matter as to whether that LSR binds multiple
labels to the address prefix (one per route), and hence distributes labels to the address prefix (one per route), and hence distributes
multiple bindings. multiple bindings.
4.1.1.1. PushUnconditional 4.1.1.1. PushUnconditional
Let Rd be an LSR. Suppose that: Let Rd be an LSR. Suppose that:
1. X is an address prefix in Rd's routing table 1. X is an address prefix in Rd's routing table
2. Ru is an LDP Peer of Rd with respect to X 2. Ru is a label distribution peer of Rd with respect to X
Whenever these conditions hold, Rd must bind a label to X and Whenever these conditions hold, Rd must bind a label to X and
distribute that binding to Ru. It is the responsibility of Rd to distribute that binding to Ru. It is the responsibility of Rd to
keep track of the bindings which it has distributed to Ru, and to keep track of the bindings which it has distributed to Ru, and to
make sure that Ru always has these bindings. make sure that Ru always has these bindings.
This procedure would be used by LSRs which are performing downstream This procedure would be used by LSRs which are performing unsolicited
label assignment in the Independent LSP Control Mode. downstream label assignment in the Independent LSP Control Mode.
4.1.1.2. PushConditional 4.1.1.2. PushConditional
Let Rd be an LSR. Suppose that: Let Rd be an LSR. Suppose that:
1. X is an address prefix in Rd's routing table 1. X is an address prefix in Rd's routing table
2. Ru is an LDP Peer of Rd with respect to X 2. Ru is a label distribution peer of Rd with respect to X
3. Rd is either an LSP Egress or an LSP Proxy Egress for X, or 3. Rd is either an LSP Egress or an LSP Proxy Egress for X, or
Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and
Rn has bound a label to X and distributed that binding to Rd. Rn has bound a label to X and distributed that binding to Rd.
Then as soon as these conditions all hold, Rd should bind a label to Then as soon as these conditions all hold, Rd should bind a label to
X and distribute that binding to Ru. X and distribute that binding to Ru.
Whereas PushUnconditional causes the distribution of label bindings Whereas PushUnconditional causes the distribution of label bindings
for all address prefixes in the routing table, PushConditional causes for all address prefixes in the routing table, PushConditional causes
the distribution of label bindings only for those address prefixes the distribution of label bindings only for those address prefixes
for which one has received label bindings from one's LSP next hop, or for which one has received label bindings from one's LSP next hop, or
for which one does not have an MPLS-capable L3 next hop. for which one does not have an MPLS-capable L3 next hop.
This procedure would be used by LSRs which are performing downstream This procedure would be used by LSRs which are performing unsolicited
label assignment in the Ordered LSP Control Mode. downstream label assignment in the Ordered LSP Control Mode.
4.1.1.3. PulledUnconditional 4.1.1.3. PulledUnconditional
Let Rd be an LSR. Suppose that: Let Rd be an LSR. Suppose that:
1. X is an address prefix in Rd's routing table 1. X is an address prefix in Rd's routing table
2. Ru is a label distribution peer of Rd with respect to X 2. Ru is a label distribution peer of Rd with respect to X
3. Ru has explicitly requested that Rd bind a label to X and 3. Ru has explicitly requested that Rd bind a label to X and
distribute the binding to Ru distribute the binding to Ru
Then Rd should bind a label to X and distribute that binding to Ru. Then Rd should bind a label to X and distribute that binding to Ru.
Note that if X is not in Rd's routing table, or if Rd is not an LDP Note that if X is not in Rd's routing table, or if Rd is not a label
peer of Ru with respect to X, then Rd must inform Ru that it cannot distribution peer of Ru with respect to X, then Rd must inform Ru
provide a binding at this time. that it cannot provide a binding at this time.
If Rd has already distributed a binding for address prefix X to Ru, If Rd has already distributed a binding for address prefix X to Ru,
and it receives a new request from Ru for a binding for address and it receives a new request from Ru for a binding for address
prefix X, it will bind a second label, and distribute the new binding prefix X, it will bind a second label, and distribute the new binding
to Ru. The first label binding remains in effect. to Ru. The first label binding remains in effect.
This procedure would be used by LSRs performing downstream-on-demand This procedure would be used by LSRs performing downstream-on-demand
label distribution using the Independent LSP Control Mode. label distribution using the Independent LSP Control Mode.
4.1.1.4. PulledConditional 4.1.1.4. PulledConditional
skipping to change at page 50, line 12 skipping to change at page 52, line 4
This procedure would be used by LSRs performing downstream-on-demand This procedure would be used by LSRs performing downstream-on-demand
label distribution using the Independent LSP Control Mode. label distribution using the Independent LSP Control Mode.
4.1.1.4. PulledConditional 4.1.1.4. PulledConditional
Let Rd be an LSR. Suppose that: Let Rd be an LSR. Suppose that:
1. X is an address prefix in Rd's routing table 1. X is an address prefix in Rd's routing table
2. Ru is a label distribution peer of Rd with respect to X 2. Ru is a label distribution peer of Rd with respect to X
3. Ru has explicitly requested that Rd bind a label to X and 3. Ru has explicitly requested that Rd bind a label to X and
distribute the binding to Ru distribute the binding to Ru
4. Rd is either an LSP Egress or an LSP Proxy Egress for X, or 4. Rd is either an LSP Egress or an LSP Proxy Egress for X, or
Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and
Rn has bound a label to X and distributed that binding to Rd Rn has bound a label to X and distributed that binding to Rd
Then as soon as these conditions all hold, Rd should bind a label to Then as soon as these conditions all hold, Rd should bind a label to
X and distribute that binding to Ru. Note that if X is not in Rd's X and distribute that binding to Ru. Note that if X is not in Rd's
routing table, or if Rd is not a label distribution peer of Ru with routing table and a binding for X is not obtainable via Rd's next hop
respect to X, then Rd must inform Ru that it cannot provide a binding for X, or if Rd is not a label distribution peer of Ru with respect
at this time. to X, then Rd must inform Ru that it cannot provide a binding at this
time.
However, if the only condition that fails to hold is that Rn has not However, if the only condition that fails to hold is that Rn has not
yet provided a label to Rd, then Rd must defer any response to Ru yet provided a label to Rd, then Rd must defer any response to Ru
until such time as it has receiving a binding from Rn. until such time as it has receiving a binding from Rn.
If Rd has distributed a label binding for address prefix X to Ru, and If Rd has distributed a label binding for address prefix X to Ru, and
at some later time, any attribute of the label binding changes, then at some later time, any attribute of the label binding changes, then
Rd must redistribute the label binding to Ru, with the new attribute. Rd must redistribute the label binding to Ru, with the new attribute.
It must do this even though Ru does not issue a new Request. It must do this even though Ru does not issue a new Request.
skipping to change at page 51, line 12 skipping to change at page 52, line 48
LSR bind a label to that prefix and distribute the binding. There LSR bind a label to that prefix and distribute the binding. There
are three possible procedures that can be used. are three possible procedures that can be used.
4.1.2.1. RequestNever 4.1.2.1. RequestNever
Never make a request. This is useful if the downstream LSR uses the Never make a request. This is useful if the downstream LSR uses the
PushConditional procedure or the PushUnconditional procedure, but is PushConditional procedure or the PushUnconditional procedure, but is
not useful if the downstream LSR uses the PulledUnconditional not useful if the downstream LSR uses the PulledUnconditional
procedure or the the PulledConditional procedures. procedure or the the PulledConditional procedures.
This procedure would be used by an LSR when downstream label This procedure would be used by an LSR when unsolicited downstream
distribution and Liberal Label Retention Mode are being used. label distribution and Liberal Label Retention Mode are being used.
4.1.2.2. RequestWhenNeeded 4.1.2.2. RequestWhenNeeded
Make a request whenever the L3 next hop to the address prefix Make a request whenever the L3 next hop to the address prefix
changes, or when a new address prefix is learned, and one doesn't changes, or when a new address prefix is learned, and one doesn't
already have a label binding from that next hop for the given address already have a label binding from that next hop for the given address
prefix. prefix.
This procedure would be used by an LSR whenever Conservative Label This procedure would be used by an LSR whenever Conservative Label
Retention Mode is being used. Retention Mode is being used.
skipping to change at page 52, line 19 skipping to change at page 54, line 11
Ru should issue the request again at a later time. That is, the Ru should issue the request again at a later time. That is, the
requester is responsible for trying again later to obtain the needed requester is responsible for trying again later to obtain the needed
binding. This procedure would be used when downstream-on-demand binding. This procedure would be used when downstream-on-demand
label distribution is used. label distribution is used.
4.1.3.2. RequestNoRetry 4.1.3.2. RequestNoRetry
Ru should never reissue the request, instead assuming that Rd will Ru should never reissue the request, instead assuming that Rd will
provide the binding automatically when it is available. This is provide the binding automatically when it is available. This is
useful if Rd uses the PushUnconditional procedure or the useful if Rd uses the PushUnconditional procedure or the
PushConditional procedure, i.e., if downstream label distribution is PushConditional procedure, i.e., if unsolicited downstream label
used. distribution is used.
Note that if Rd replies that it cannot provide a binding to Ru, Note that if Rd replies that it cannot provide a binding to Ru,
because of some error condition, rather than because Rd has no next because of some error condition, rather than because Rd has no next
hop, the behavior of Ru will be governed by the error recovery hop, the behavior of Ru will be governed by the error recovery
conditions of the label distribution protocol, rather than by the conditions of the label distribution protocol, rather than by the
NotAvailable procedure. NotAvailable procedure.
4.1.4. Upstream LSR: Release Procedure 4.1.4. Upstream LSR: Release Procedure
Suppose that Rd is an LSR which has bound a label to address prefix Suppose that Rd is an LSR which has bound a label to address prefix
skipping to change at page 53, line 32 skipping to change at page 55, line 26
4.1.5.1. UseImmediate 4.1.5.1. UseImmediate
Ru may put the binding into use immediately. At any time when Ru has Ru may put the binding into use immediately. At any time when Ru has
a binding for X from Rd, and Rd is Ru's L3 next hop for X, Rd will a binding for X from Rd, and Rd is Ru's L3 next hop for X, Rd will
also be Ru's LSP next hop for X. This procedure is used when loop also be Ru's LSP next hop for X. This procedure is used when loop
detection is not in use. detection is not in use.
4.1.5.2. UseIfLoopNotDetected 4.1.5.2. UseIfLoopNotDetected
This procedure is the same as UseImmediate, unless Ru has detected a This procedure is the same as UseImmediate, unless Ru has detected a
loop in the LSP. If a loop has been detected, Ru will discard loop in the LSP. If a loop has been detected, Ru will discontinue
packets that would otherwise have been labeled with L and sent to Rd. the use of label L for forwarding packets to Rd.
This procedure is used when loop detection is in use. This procedure is used when loop detection is in use.
This will continue until the next hop for X changes, or until the This will continue until the next hop for X changes, or until the
loop is no longer detected. loop is no longer detected.
4.1.6. Downstream LSR: Withdraw Procedure 4.1.6. Downstream LSR: Withdraw Procedure
In this case, there is only a single procedure. In this case, there is only a single procedure.
skipping to change at page 54, line 11 skipping to change at page 56, line 6
It is required that the unbinding of L from X be distributed by Rd to It is required that the unbinding of L from X be distributed by Rd to
a LSR Ru before Rd distributes to Ru any new binding of L to any a LSR Ru before Rd distributes to Ru any new binding of L to any
other address prefix Y, where X != Y. If Ru were to learn of the new other address prefix Y, where X != Y. If Ru were to learn of the new
binding of L to Y before it learned of the unbinding of L from X, and binding of L to Y before it learned of the unbinding of L from X, and
if packets matching both X and Y were forwarded by Ru to Rd, then for if packets matching both X and Y were forwarded by Ru to Rd, then for
a period of time, Ru would label both packets matching X and packets a period of time, Ru would label both packets matching X and packets
matching Y with label L. matching Y with label L.
The distribution and withdrawal of label bindings is done via a label The distribution and withdrawal of label bindings is done via a label
distribution protocol, or LDP. LDP is a two-party protocol. If LSR R1 distribution protocol. All label distribution protocols require that
has received label bindings from LSR R2 via an instance of an LDP, a label distribution adjacency be established between two label
and that instance of that protocol is closed by either end (whether distribution peers (except implicit peers). If LSR R1 has a label
as a result of failure or as a matter of normal operation), then all distribution adjacency to LSR R2, and has received label bindings
bindings learned over that instance of the protocol must be from LSR R2 via that adjacency, then if adjacency is brought down by
either peer (whether as a result of failure or as a matter of normal
operation), all bindings received over that adjacency must be
considered to have been withdrawn. considered to have been withdrawn.
As long as the relevant LDP connection remains open, label bindings As long as the relevant label distribution adjacency remains in
that are withdrawn must always be withdrawn explicitly. If a second place, label bindings that are withdrawn must always be withdrawn
label is bound to an address prefix, the result is not to implicitly explicitly. If a second label is bound to an address prefix, the
withdraw the first label, but to bind both labels; this is needed to result is not to implicitly withdraw the first label, but to bind
support multi-path routing. If a second address prefix is bound to a both labels; this is needed to support multi-path routing. If a
label, the result is not to implicitly withdraw the binding of that second address prefix is bound to a label, the result is not to
label to the first address prefix, but to use that label for both implicitly withdraw the binding of that label to the first address
address prefixes. prefix, but to use that label for both address prefixes.
4.2. MPLS Schemes: Supported Combinations of Procedures 4.2. MPLS Schemes: Supported Combinations of Procedures
Consider two LSRs, Ru and Rd, which are label distribution peers with Consider two LSRs, Ru and Rd, which are label distribution peers with
respect to some set of address prefixes, where Ru is the upstream respect to some set of address prefixes, where Ru is the upstream
peer and Rd is the downstream peer. peer and Rd is the downstream peer.
The MPLS scheme which governs the interaction of Ru and Rd can be The MPLS scheme which governs the interaction of Ru and Rd can be
described as a quintuple of procedures: <Distribution Procedure, described as a quintuple of procedures: <Distribution Procedure,
Request Procedure, NotAvailable Procedure, Release Procedure, Request Procedure, NotAvailable Procedure, Release Procedure,
skipping to change at page 55, line 13 skipping to change at page 57, line 8
need for them is shown. need for them is shown.
4.2.1. Schemes for LSRs that Support Label Merging 4.2.1. Schemes for LSRs that Support Label Merging
If Ru and Rd are label distribution peers, and both support label If Ru and Rd are label distribution peers, and both support label
merging, one of the following schemes must be used: merging, one of the following schemes must be used:
1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, 1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange,
UseImmediate> UseImmediate>
This is downstream label distribution with independent control, This is unsolicited downstream label distribution with
liberal label retention mode, and no loop detection. independent control, liberal label retention mode, and no loop
detection.
2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, 2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange,
UseIfLoopNotDetected> UseIfLoopNotDetected>
This is downstream label distribution with independent control, This is unsolicited downstream label distribution with
liberal label retention, and loop detection. independent control, liberal label retention, and loop
detection.
3. <PushConditional, RequestWhenNeeded, RequestNoRetry, 3. <PushConditional, RequestWhenNeeded, RequestNoRetry,
ReleaseOnChange, *> ReleaseOnChange, *>
This is downstream label distribution with ordered control This is unsolicited downstream label distribution with ordered
(from the egress) and conservative label retention mode. Loop control (from the egress) and conservative label retention
detection is optional. mode. Loop detection is optional.
4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *> 4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>
This is downstream label distribution with ordered control This is unsolicited downstream label distribution with ordered
(from the egress) and liberal label retention mode. Loop control (from the egress) and liberal label retention mode.
detection is optional. Loop detection is optional.
5. <PulledConditional, RequestWhenNeeded, RequestRetry, 5. <PulledConditional, RequestWhenNeeded, RequestRetry,
ReleaseOnChange, *> ReleaseOnChange, *>
This is downstream-on-demand label distribution with ordered This is downstream-on-demand label distribution with ordered
control (initiated by the ingress), conservative label control (initiated by the ingress), conservative label
retention mode, and optional loop detection. retention mode, and optional loop detection.
6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, 6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange,
UseImmediate> UseImmediate>
skipping to change at page 57, line 26 skipping to change at page 59, line 26
viable, since they will not result in the proper distribution of viable, since they will not result in the proper distribution of
label bindings. label bindings.
- <*, RequestNever, *, *, ReleaseOnChange> - <*, RequestNever, *, *, ReleaseOnChange>
In these MPLS schemes, Rd releases bindings when it isn't using In these MPLS schemes, Rd releases bindings when it isn't using
them, but it never asks for them again, even if it later has a them, but it never asks for them again, even if it later has a
need for them. These schemes thus do not ensure that label need for them. These schemes thus do not ensure that label
bindings get properly distributed. bindings get properly distributed.
In this section, we specify rules to prevent a pair of LDP peers from In this section, we specify rules to prevent a pair of label
adopting procedures which lead to infeasible MPLS Schemes. These distribution peers from adopting procedures which lead to infeasible
rules require the exchange of information between LDP peers during MPLS Schemes. These rules require either the exchange of information
the initialization of the LDP connection between them. between label distribution peers during the initialization of the
label distribution adjacency, or apriori knowledge of the information
(obtained through a means outside the scope of this document).
1. Each must state whether it supports label merging. 1. Each must state whether it supports label merging.
2. If Rd does not support label merging, Rd must choose either the 2. If Rd does not support label merging, Rd must choose either the
PulledUnconditional procedure or the PulledConditional PulledUnconditional procedure or the PulledConditional
procedure. If Rd chooses PulledConditional, Ru is forced to procedure. If Rd chooses PulledConditional, Ru is forced to
use the RequestRetry procedure. use the RequestRetry procedure.
That is, if the downstream LSR does not support label merging, That is, if the downstream LSR does not support label merging,
its preferences take priority when the MPLS scheme is chosen. its preferences take priority when the MPLS scheme is chosen.
skipping to change at page 58, line 19 skipping to change at page 60, line 24
PushConditional, PulledConditional, or PulledUnconditional. PushConditional, PulledConditional, or PulledUnconditional.
These choices together determine the MPLS scheme in use. These choices together determine the MPLS scheme in use.
5. Security Considerations 5. Security Considerations
Some routers may implement security procedures which depend on the Some routers may implement security procedures which depend on the
network layer header being in a fixed place relative to the data link network layer header being in a fixed place relative to the data link
layer header. The MPLS generic encapsulation inserts a shim between layer header. The MPLS generic encapsulation inserts a shim between
the data link layer header and the network layer header. This may the data link layer header and the network layer header. This may
cause such any security procedures to fail. cause such any such security procedures to fail.
An MPLS label has its meaning by virtue of an agreement between the An MPLS label has its meaning by virtue of an agreement between the
LSR that puts the label in the label stack (the "label writer") , and LSR that puts the label in the label stack (the "label writer") , and
the LSR that interprets that label (the "label reader"). If labeled the LSR that interprets that label (the "label reader"). If labeled
packets are accepted from untrusted sources, or if a particular packets are accepted from untrusted sources, or if a particular
incoming label is accepted from an LSR to which that label has not incoming label is accepted from an LSR to which that label has not
been distributed, then packets may be routed in an illegitimate been distributed, then packets may be routed in an illegitimate
manner. manner.
6. Intellectual Property 6. Intellectual Property
skipping to change at page 59, line 22 skipping to change at page 61, line 27
8. References 8. References
[MPLS-ATM] "MPLS using ATM VC Switching", Davie, Doolan, Lawrence, [MPLS-ATM] "MPLS using ATM VC Switching", Davie, Doolan, Lawrence,
McGloghrie, Rekhter, Rosen, Swallow, work in progress, Internet Draft McGloghrie, Rekhter, Rosen, Swallow, work in progress, Internet Draft
<draft-ietf-mpls-atm-01.txt>, November 1998. <draft-ietf-mpls-atm-01.txt>, November 1998.
[MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, [MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen,
work in progress, Internet Draft <draft-ietf-mpls-bgp4-mpls-01.txt>, work in progress, Internet Draft <draft-ietf-mpls-bgp4-mpls-01.txt>,
August 1998. August 1998.
[MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Andersson,
Fredette, Jamoussi, Callon, Doolan, Feldman, Gray, Halpern, Heinanen,
Kilty, Malis, Girish, Sundell, Vaananen, Worster, Wu, Dantu, Internet
Draft <draft-ietf-mpls-cr-ldp-00.txt>, January 1999.
[MPLS-FRMWRK] "A Framework for Multiprotocol Label Switching", [MPLS-FRMWRK] "A Framework for Multiprotocol Label Switching",
Callon, Doolan, Feldman, Fredette, Swallow, Viswanathan, work in Callon, Doolan, Feldman, Fredette, Swallow, Viswanathan, work in
progress, Internet Draft <draft-ietf-mpls-framework-02.txt>, November progress, Internet Draft <draft-ietf-mpls-framework-02.txt>, November
1997 1997
[MPLS-FRMRLY] "Use of Label Switching on Frame Relay Networks", [MPLS-FRMRLY] "Use of Label Switching on Frame Relay Networks",
Conta, Doolan, Malis, work in progress, Internet Draft <draft-ietf- Conta, Doolan, Malis, work in progress, Internet Draft <draft-ietf-
mpls-fr-03.txt>, November 1998 mpls-fr-03.txt>, November 1998
 End of changes. 

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