rfc3031.txt

最新的RFC

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.






Rosen, et al.               Standards Track                     [Page 5]

RFC 3031                   MPLS Architecture                January 2001