📄 rfc3031.txt
字号:
Network Working Group E. Rosen
Request for Comments: 3031 Cisco Systems, Inc.
Category: Standards Track A. Viswanathan
Force10 Networks, Inc.
R. Callon
Juniper Networks, Inc.
January 2001
Multiprotocol Label Switching Architecture
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document specifies the architecture for Multiprotocol Label
Switching (MPLS).
Table of Contents
1 Specification ...................................... 3
2 Introduction to MPLS ............................... 3
2.1 Overview ........................................... 4
2.2 Terminology ........................................ 6
2.3 Acronyms and Abbreviations ......................... 9
2.4 Acknowledgments .................................... 9
3 MPLS Basics ........................................ 9
3.1 Labels ............................................. 9
3.2 Upstream and Downstream LSRs ....................... 10
3.3 Labeled Packet ..................................... 11
3.4 Label Assignment and Distribution .................. 11
3.5 Attributes of a Label Binding ...................... 11
3.6 Label Distribution Protocols ....................... 11
3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12
3.8 Label Retention Mode ............................... 12
3.9 The Label Stack .................................... 13
3.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 13
3.11 Incoming Label Map (ILM) ........................... 14
Rosen, et al. Standards Track [Page 1]
RFC 3031 MPLS Architecture January 2001
3.12 FEC-to-NHLFE Map (FTN) ............................. 14
3.13 Label Swapping ..................................... 15
3.14 Scope and Uniqueness of Labels ..................... 15
3.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 16
3.16 Penultimate Hop Popping ............................ 18
3.17 LSP Next Hop ....................................... 20
3.18 Invalid Incoming Labels ............................ 20
3.19 LSP Control: Ordered versus Independent ............ 20
3.20 Aggregation ........................................ 21
3.21 Route Selection .................................... 23
3.22 Lack of Outgoing Label ............................. 24
3.23 Time-to-Live (TTL) ................................. 24
3.24 Loop Control ....................................... 25
3.25 Label Encodings .................................... 26
3.25.1 MPLS-specific Hardware and/or Software ............. 26
3.25.2 ATM Switches as LSRs ............................... 26
3.25.3 Interoperability among Encoding Techniques ......... 28
3.26 Label Merging ...................................... 28
3.26.1 Non-merging LSRs ................................... 29
3.26.2 Labels for Merging and Non-Merging LSRs ............ 30
3.26.3 Merge over ATM ..................................... 31
3.26.3.1 Methods of Eliminating Cell Interleave ............. 31
3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 31
3.27 Tunnels and Hierarchy .............................. 32
3.27.1 Hop-by-Hop Routed Tunnel ........................... 32
3.27.2 Explicitly Routed Tunnel ........................... 33
3.27.3 LSP Tunnels ........................................ 33
3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 33
3.27.5 Label Distribution Peering and Hierarchy ........... 34
3.28 Label Distribution Protocol Transport .............. 35
3.29 Why More than one Label Distribution Protocol? ..... 36
3.29.1 BGP and LDP ........................................ 36
3.29.2 Labels for RSVP Flowspecs .......................... 36
3.29.3 Labels for Explicitly Routed LSPs .................. 36
3.30 Multicast .......................................... 37
4 Some Applications of MPLS .......................... 37
4.1 MPLS and Hop by Hop Routed Traffic ................. 37
4.1.1 Labels for Address Prefixes ........................ 37
4.1.2 Distributing Labels for Address Prefixes ........... 37
4.1.2.1 Label Distribution Peers for an Address Prefix ..... 37
4.1.2.2 Distributing Labels ................................ 38
4.1.3 Using the Hop by Hop path as the LSP ............... 39
4.1.4 LSP Egress and LSP Proxy Egress .................... 39
4.1.5 The Implicit NULL Label ............................ 40
4.1.6 Option: Egress-Targeted Label Assignment ........... 40
4.2 MPLS and Explicitly Routed LSPs .................... 42
4.2.1 Explicitly Routed LSP Tunnels ...................... 42
4.3 Label Stacks and Implicit Peering .................. 43
Rosen, et al. Standards Track [Page 2]
RFC 3031 MPLS Architecture January 2001
4.4 MPLS and Multi-Path Routing ........................ 44
4.5 LSP Trees as Multipoint-to-Point Entities .......... 44
4.6 LSP Tunneling between BGP Border Routers ........... 45
4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 47
4.8 MPLS and Multicast ................................. 47
5 Label Distribution Procedures (Hop-by-Hop) ......... 47
5.1 The Procedures for Advertising and Using labels .... 48
5.1.1 Downstream LSR: Distribution Procedure ............. 48
5.1.1.1 PushUnconditional .................................. 49
5.1.1.2 PushConditional .................................... 49
5.1.1.3 PulledUnconditional ................................ 49
5.1.1.4 PulledConditional .................................. 50
5.1.2 Upstream LSR: Request Procedure .................... 51
5.1.2.1 RequestNever ....................................... 51
5.1.2.2 RequestWhenNeeded .................................. 51
5.1.2.3 RequestOnRequest ................................... 51
5.1.3 Upstream LSR: NotAvailable Procedure ............... 52
5.1.3.1 RequestRetry ....................................... 52
5.1.3.2 RequestNoRetry ..................................... 52
5.1.4 Upstream LSR: Release Procedure .................... 52
5.1.4.1 ReleaseOnChange .................................... 52
5.1.4.2 NoReleaseOnChange .................................. 53
5.1.5 Upstream LSR: labelUse Procedure ................... 53
5.1.5.1 UseImmediate ....................................... 53
5.1.5.2 UseIfLoopNotDetected ............................... 53
5.1.6 Downstream LSR: Withdraw Procedure ................. 53
5.2 MPLS Schemes: Supported Combinations of Procedures . 54
5.2.1 Schemes for LSRs that Support Label Merging ........ 55
5.2.2 Schemes for LSRs that do not Support Label Merging . 56
5.2.3 Interoperability Considerations .................... 57
6 Security Considerations ............................ 58
7 Intellectual Property .............................. 58
8 Authors' Addresses ................................. 59
9 References ......................................... 59
10 Full Copyright Statement ........................... 61
1. Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Introduction to MPLS
This document specifies the architecture for Multiprotocol Label
Switching (MPLS).
Note that the use of MPLS for multicast is left for further study.
Rosen, et al. Standards Track [Page 3]
RFC 3031 MPLS Architecture January 2001
2.1. Overview
As a packet of a connectionless network layer protocol travels from
one router to the next, each router makes an independent forwarding
decision for that packet. That is, each router analyzes the packet's
header, and each router runs a network layer routing algorithm. Each
router independently chooses a next hop for the packet, based on its
analysis of the packet's header and the results of running the
routing algorithm.
Packet headers contain considerably more information than is needed
simply to choose the next hop. Choosing the next hop can therefore
be thought of as the composition of two functions. The first
function partitions the entire set of possible packets into a set of
"Forwarding Equivalence Classes (FECs)". The second maps each FEC to
a next hop. Insofar as the forwarding decision is concerned,
different packets which get mapped into the same FEC are
indistinguishable. All packets which belong to a particular FEC and
which travel from a particular node will follow the same path (or if
certain kinds of multi-path routing are in use, they will all follow
one of a set of paths associated with the FEC).
In conventional IP forwarding, a particular router will typically
consider two packets to be in the same FEC if there is some address
prefix X in that router's routing tables such that X is the "longest
match" for each packet's destination address. As the packet
traverses the network, each hop in turn reexamines the packet and
assigns it to a FEC.
In MPLS, the assignment of a particular packet to a particular FEC is
done just once, as the packet enters the network. The FEC to which
the packet is assigned is encoded as a short fixed length value known
as a "label". When a packet is forwarded to its next hop, the label
is sent along with it; that is, the packets are "labeled" before they
are forwarded.
At subsequent hops, there is no further analysis of the packet's
network layer header. Rather, the label is used as an index into a
table which specifies the next hop, and a new label. The old label
is replaced with the new label, and the packet is forwarded to its
next hop.
In the MPLS forwarding paradigm, once a packet is assigned to a FEC,
no further header analysis is done by subsequent routers; all
forwarding is driven by the labels. This has a number of advantages
over conventional network layer forwarding.
Rosen, et al. Standards Track [Page 4]
RFC 3031 MPLS Architecture January 2001
- MPLS forwarding can be done by switches which are capable of
doing label lookup and replacement, but are either not capable
of analyzing the network layer headers, or are not capable of
analyzing the network layer headers at adequate speed.
- Since a packet is assigned to a FEC when it enters the network,
the ingress router may use, in determining the assignment, any
information it has about the packet, even if that information
cannot be gleaned from the network layer header. For example,
packets arriving on different ports may be assigned to
different FECs. Conventional forwarding, on the other hand,
can only consider information which travels with the packet in
the packet header.
- A packet that enters the network at a particular router can be
labeled differently than the same packet entering the network
at a different router, and as a result forwarding decisions
that depend on the ingress router can be easily made. This
cannot be done with conventional forwarding, since the identity
of a packet's ingress router does not travel with the packet.
- The considerations that determine how a packet is assigned to a
FEC can become ever more and more complicated, without any
impact at all on the routers that merely forward labeled
packets.
- Sometimes it is desirable to force a packet to follow a
particular route which is explicitly chosen at or before the
time the packet enters the network, rather than being chosen by
the normal dynamic routing algorithm as the packet travels
through the network. This may be done as a matter of policy,
or to support traffic engineering. In conventional forwarding,
this requires the packet to carry an encoding of its route
along with it ("source routing"). In MPLS, a label can be used
to represent the route, so that the identity of the explicit
route need not be carried with the packet.
Some routers analyze a packet's network layer header not merely to
choose the packet's next hop, but also to determine a packet's
"precedence" or "class of service". They may then apply different
discard thresholds or scheduling disciplines to different packets.
MPLS allows (but does not require) the precedence or class of service
to be fully or partially inferred from the label. In this case, one
may say that the label represents the combination of a FEC and a
precedence or class of service.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -