Network Working Group
`Internet Draft
`Expiration Date: January 1998
`
`Eric C. Rosen
`Cisco Systems, Inc.
`
`Arun Viswanathan
`IBM Corp.
`
`Ross Callon
`Ascend Communications, Inc.
`
`July 1997
`
`A Proposed Architecture for MPLS
`
`draft-rosen-mpls-arch-00.txt
`
`Status of this Memo
`
` This document is an Internet-Draft. Internet-Drafts are working
` documents of the Internet Engineering Task Force (IETF), its areas,
` and its working groups. Note that other groups may also distribute
` working documents as Internet-Drafts.
`
` Internet-Drafts are draft documents valid for a maximum of six months
` and may be updated, replaced, or obsoleted by other documents at any
` time. It is inappropriate to use Internet-Drafts as reference
` material or to cite them other than as "work in progress."
`
` To learn the current status of any Internet-Draft, please check the
` "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
` Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
` munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
` ftp.isi.edu (US West Coast).
`
`Abstract
`
` This internet draft contains a draft protocol architecture for
` multiprotocol label switching (MPLS). The proposed architecture is
` based on other label switching approaches [2-11] as well as on the
` MPLS Framework document [1].
`
`Rosen, Viswanathan & Callon
`
`[Page 1]
`
`EX1013
`Palo Alto Networks v. Sable Networks
`IPR2021-00051
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
`Table of Contents
`
` 1 Introduction to MPLS ............................... 3
` 1.1 Overview ........................................... 3
` 1.2 Terminology ........................................ 5
` 1.3 Acronyms and Abbreviations ......................... 9
` 1.4 Acknowledgments .................................... 10
` 2 Outline of Approach ................................ 10
` 2.1 Labels ............................................. 10
` 2.2 Upstream and Downstream LSRs ....................... 11
` 2.3 Labeled Packet ..................................... 11
` 2.4 Label Assignment and Distribution; Attributes ...... 11
` 2.5 Label Distribution Protocol (LDP) .................. 12
` 2.6 The Label Stack .................................... 12
` 2.7 The Next Hop Label Forwarding Entry (NHLFE) ........ 13
` 2.8 Incoming Label Map (ILM) ........................... 13
` 2.9 Stream-to-NHLFE Map (STN) .......................... 13
` 2.10 Label Swapping ..................................... 14
` 2.11 Label Switched Path (LSP), LSP Ingress, LSP Egress . 14
` 2.12 LSP Next Hop ....................................... 16
` 2.13 Route Selection .................................... 17
` 2.14 Time-to-Live (TTL) ................................. 18
` 2.15 Loop Control ....................................... 19
` 2.15.1 Loop Prevention .................................... 20
` 2.15.2 Interworking of Loop Control Options ............... 22
` 2.16 Merging and Non-Merging LSRs ....................... 23
` 2.16.1 Stream Merge ....................................... 24
` 2.16.2 Non-merging LSRs ................................... 24
` 2.16.3 Labels for Merging and Non-Merging LSRs ............ 25
` 2.16.4 Merge over ATM ..................................... 26
` 2.16.4.1 Methods of Eliminating Cell Interleave ............. 26
` 2.16.4.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 26
` 2.17 LSP Control: Egress versus Local ................... 27
` 2.18 Granularity ........................................ 29
` 2.19 Tunnels and Hierarchy .............................. 30
` 2.19.1 Hop-by-Hop Routed Tunnel ........................... 30
` 2.19.2 Explicitly Routed Tunnel ........................... 30
` 2.19.3 LSP Tunnels ........................................ 30
` 2.19.4 Hierarchy: LSP Tunnels within LSPs ................. 31
` 2.19.5 LDP Peering and Hierarchy .......................... 31
` 2.20 LDP Transport ...................................... 33
` 2.21 Label Encodings .................................... 33
` 2.21.1 MPLS-specific Hardware and/or Software ............. 33
` 2.21.2 ATM Switches as LSRs ............................... 34
` 2.21.3 Interoperability among Encoding Techniques ......... 35
` 2.22 Multicast .......................................... 36
`
`Rosen, Viswanathan & Callon [Page 2]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
` 3 Some Applications of MPLS .......................... 36
` 3.1 MPLS and Hop by Hop Routed Traffic ................. 36
` 3.1.1 Labels for Address Prefixes ........................ 36
` 3.1.2 Distributing Labels for Address Prefixes ........... 36
` 3.1.2.1 LDP Peers for a Particular Address Prefix .......... 36
` 3.1.2.2 Distributing Labels ................................ 37
` 3.1.3 Using the Hop by Hop path as the LSP ............... 38
` 3.1.4 LSP Egress and LSP Proxy Egress .................... 38
` 3.1.5 The POP Label ...................................... 39
` 3.1.6 Option: Egress-Targeted Label Assignment ........... 40
` 3.2 MPLS and Explicitly Routed LSPs .................... 41
` 3.2.1 Explicitly Routed LSP Tunnels: Traffic Engineering . 42
` 3.3 Label Stacks and Implicit Peering .................. 42
` 3.4 MPLS and Multi-Path Routing ........................ 43
` 3.5 LSPs may be Multipoint-to-Point Entities ........... 44
` 3.6 LSP Tunneling between BGP Border Routers ........... 44
` 3.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 46
` 3.8 MPLS and Multicast ................................. 46
` 4 LDP Procedures ..................................... 47
` 5 Security Considerations ............................ 47
` 6 Authors’ Addresses ................................. 47
` 7 References ......................................... 47
` Appendix A Why Egress Control is Better ....................... 48
` Appendix B Why Local Control is Better ........................ 56
`
`1. Introduction to MPLS
`
`1.1. Overview
`
` In connectionless network layer protocols, as a packet travels from
` one router hop to the next, an independent forwarding decision is
` made at each hop. Each router analyzes the packet header, and runs a
` network layer routing algorithm. The next hop for a packet is chosen
` based on the header analysis and the result 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 packet forwarding space into "forwarding
` equivalence classes (FECs)". The second maps these FECs to a next
` hop. Multiple network layer headers which get mapped into the same
` FEC are indistinguishable, as far as the forwarding decision is
` concerned. The set of packets belonging to the same FEC, traveling
` from a common node, will follow the same path and be forwarded in the
`
`Rosen, Viswanathan & Callon [Page 3]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
` same manner (for example, by being placed in a common queue) towards
` the destination. This set of packets following the same path,
` belonging to the same FEC (and therefore being forwarded in a common
` manner) may be referred to as a "stream".
`
` In IP forwarding, multiple packets are typically assigned to the same
` Stream by a particular router 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.
`
` In MPLS, the mapping from packet headers to stream is performed just
` once, as the packet enters the network. The stream to which the
` packet is assigned is encoded with 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".
`
` At subsequent hops, there is no further analysis of the 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. This
` eliminates the need to perform a longest match computation for each
` packet at each hop; the computation can be performed just once.
`
` 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", in order to apply different
` discard thresholds or scheduling disciplines to different packets. In
` MPLS, this can also be inferred from the label, so that no further
` header analysis is needed.
`
` The fact that a packet is assigned to a Stream just once, rather than
` at every hop, allows the use of sophisticated forwarding paradigms.
` 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 point ("policy routing") can be easily made. In fact,
` the policy used to assign a packet to a Stream need not have only the
` network layer header as input; it may use arbitrary information about
` the packet, and/or arbitrary policy information as input. Since this
` decouples forwarding from routing, it allows one to use MPLS to
` support a large variety of routing policies that are difficult or
` impossible to support with just conventional network layer
` forwarding.
`
` Similarly, MPLS facilitates the use of explicit routing, without
` requiring that each IP packet carry the explicit route. Explicit
` routes may be useful to support policy routing and traffic
` engineering.
`
`Rosen, Viswanathan & Callon [Page 4]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
` MPLS makes use of a routing approach whereby the normal mode of
` operation is that L3 routing (e.g., existing IP routing protocols
` and/or new IP routing protocols) is used by all nodes to determine
` the routed path.
`
` MPLS stands for "Multiprotocol" Label Switching, multiprotocol
` because its techniques are applicable to ANY network layer protocol.
` In this document, however, we focus on the use of IP as the network
` layer protocol.
`
` A router which supports MPLS is known as a "Label Switching Router",
` or LSR.
`
` A general discussion of issues related to MPLS is presented in "A
` Framework for Multiprotocol Label Switching" [1].
`
`1.2. Terminology
`
` This section gives a general conceptual overview of the terms used in
` this document. Some of these terms are more precisely defined in
` later sections of the document.
`
` aggregate stream synonym of "stream"
`
` DLCI a label used in Frame Relay networks to
` identify frame relay circuits
`
` flow a single instance of an application to
` application flow of data (as in the RSVP
` and IFMP use of the term "flow")
`
` forwarding equivalence class a group of IP packets which are
` forwarded in the same manner (e.g.,
` over the same path, with the same
` forwarding treatment)
`
` frame merge stream merge, when it is applied to
` operation over frame based media, so that
` the potential problem of cell interleave
` is not an issue.
`
` label a short fixed length physically
` contiguous identifier which is used to
` identify a stream, usually of local
` significance.
`
`Rosen, Viswanathan & Callon [Page 5]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
` label information base the database of information containing
` label bindings
`
` label swap the basic forwarding operation consisting
` of looking up an incoming label to
` determine the outgoing label,
` encapsulation, port, and other data
` handling information.
`
` label swapping a forwarding paradigm allowing
` streamlined forwarding of data by using
` labels to identify streams of data to be
` forwarded.
`
` label switched hop the hop between two MPLS nodes, on which
` forwarding is done using labels.
`
` label switched path the path created by the concatenation of
` one or more label switched hops, allowing
` a packet to be forwarded by swapping
` labels from an MPLS node to another MPLS
` node.
`
` layer 2 the protocol layer under layer 3 (which
` therefore offers the services used by
` layer 3). Forwarding, when done by the
` swapping of short fixed length labels,
` occurs at layer 2 regardless of whether
` the label being examined is an ATM
` VPI/VCI, a frame relay DLCI, or an MPLS
` label.
`
` layer 3 the protocol layer at which IP and its
` associated routing protocols operate link
` layer synonymous with layer 2
`
` loop detection a method of dealing with loops in which
` loops are allowed to be set up, and data
` may be transmitted over the loop, but the
` loop is later detected and closed
`
` loop prevention a method of dealing with loops in which
` data is never transmitted over a loop
`
` label stack an ordered set of labels
`
`Rosen, Viswanathan & Callon [Page 6]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
` loop survival a method of dealing with loops in which
` data may be transmitted over a loop, but
` means are employed to limit the amount of
` network resources which may be consumed
` by the looping data
`
` label switched path The path through one or more LSRs at one
` level of the hierarchy followed by a
` stream.
`
` label switching router an MPLS node which is capable of
` forwarding native L3 packets
`
` merge point the node at which multiple streams and
` switched paths are combined into a single
` stream sent over a single path.
`
` Mlabel abbreviation for MPLS label
`
` MPLS core standards the standards which describe the core
` MPLS technology
`
` MPLS domain a contiguous set of nodes which operate
` MPLS routing and forwarding and which are
` also in one Routing or Administrative
` Domain
`
` MPLS edge node an MPLS node that connects an MPLS domain
` with a node which is outside of the
` domain, either because it does not run
` MPLS, and/or because it is in a different
` domain. Note that if an LSR has a
` neighboring host which is not running
` MPLS, that that LSR is an MPLS edge node.
`
` MPLS egress node an MPLS edge node in its role in handling
` traffic as it leaves an MPLS domain
`
` MPLS ingress node an MPLS edge node in its role in handling
` traffic as it enters an MPLS domain
`
` MPLS label a label placed in a short MPLS shim
` header used to identify streams
`
` MPLS node a node which is running MPLS. An MPLS
` node will be aware of MPLS control
` protocols, will operate one or more L3
` routing protocols, and will be capable of
`
`Rosen, Viswanathan & Callon [Page 7]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
` forwarding packets based on labels. An
` MPLS node may optionally be also capable
` of forwarding native L3 packets.
`
` MultiProtocol Label Switching an IETF working group and the effort
` associated with the working group
`
` network layer synonymous with layer 3
`
` stack synonymous with label stack
`
` stream an aggregate of one or more flows,
` treated as one aggregate for the purpose
` of forwarding in L2 and/or L3 nodes
` (e.g., may be described using a single
` label). In many cases a stream may be the
` aggregate of a very large number of
` flows. Synonymous with "aggregate
` stream".
`
` stream merge the merging of several smaller streams
` into a larger stream, such that for some
` or all of the path the larger stream can
` be referred to using a single label.
`
` switched path synonymous with label switched path
`
` virtual circuit a circuit used by a connection-oriented
` layer 2 technology such as ATM or Frame
` Relay, requiring the maintenance of state
` information in layer 2 switches.
`
` VC merge stream merge when it is specifically
` applied to VCs, specifically so as to
` allow multiple VCs to merge into one
` single VC
`
` VP merge stream merge when it is applied to VPs,
` specifically so as to allow multiple VPs
` to merge into one single VP. In this case
` the VCIs need to be unique. This allows
` cells from different sources to be
` distinguished via the VCI.
`
` VPI/VCI a label used in ATM networks to identify
` circuits
`
`Rosen, Viswanathan & Callon [Page 8]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
`1.3. Acronyms and Abbreviations
`
` ATM Asynchronous Transfer Mode
`
` BGP Border Gateway Protocol
`
` DLCI Data Link Circuit Identifier
`
` FEC Forwarding Equivalence Class
`
` STN Stream to NHLFE Map
`
` IGP Interior Gateway Protocol
`
` ILM Incoming Label Map
`
` IP Internet Protocol
`
` LIB Label Information Base
`
` LDP Label Distribution Protocol
`
` L2 Layer 2
`
` L3 Layer 3
`
` LSP Label Switched Path
`
` LSR Label Switching Router
`
` MPLS MultiProtocol Label Switching
`
` MPT Multipoint to Point Tree
`
` NHLFE Next Hop Label Forwarding Entry
`
` SVC Switched Virtual Circuit
`
` SVP Switched Virtual Path
`
` TTL Time-To-Live
`
` VC Virtual Circuit
`
` VCI Virtual Circuit Identifier
`
` VP Virtual Path
`
`Rosen, Viswanathan & Callon [Page 9]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
` VPI Virtual Path Identifier
`
`1.4. Acknowledgments
`
` The ideas and text in this document have been collected from a number
` of sources and comments received. We would like to thank Rick Boivie,
` Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan, and
` George Swallow for their inputs and ideas.
`
`2. Outline of Approach
`
` In this section, we introduce some of the basic concepts of MPLS and
` describe the general approach to be used.
`
`2.1. Labels
`
` A label is a short fixed length locally significant identifier which
` is used to identify a stream. The label is based on the stream or
` forwarding equivalence class that a packet is assigned to. The label
` does not directly encode the network layer address, and is based on
` the network layer address only to the extent that the forwarding
` equivalence class is based on the address.
`
` If Ru and Rd are neighboring LSRs, they may agree to use label L to
` represent Stream S for packets which are sent from Ru to Rd. That
` is, they can agree to a "mapping" between label L and Stream S for
` packets moving from Ru to Rd. As a result of such an agreement, L
` becomes Ru’s "outgoing label" corresponding to Stream S for such
` packets; L becomes Rd’s "incoming label" corresponding to Stream S
` for such packets.
`
` Note that L does not necessarily correspond to Stream S for any
` packets other than those which are being sent from Ru to Rd. Also, L
` is not an inherently meaningful value and does not have any network-
` wide value; the particular value assigned to L gets its meaning
` solely from the agreement between Ru and Rd.
`
` Sometimes it may be difficult or even impossible for Rd to tell that
` an arriving packet carrying label L comes from Ru, rather than from
` some other LSR. In such cases, Rd must make sure that the mapping
` from label to FEC is one-to-one. That is, in such cases, Rd must not
` agree with Ru1 to use L for one purpose, while also agreeing with
` some other LSR Ru2 to use L for a different purpose.
`
`Rosen, Viswanathan & Callon [Page 10]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
` The scope of labels could be unique per interface, or unique per MPLS
` node, or unique in a network. If labels are unique within a network,
` no label swapping needs to be performed in the MPLS nodes in that
` domain. The packets are just label forwarded and not label swapped.
` The possible use of labels with network-wide scope is FFS.
`
`2.2. Upstream and Downstream LSRs
`
` Suppose Ru and Rd have agreed to map label L to Stream S, for packets
` sent from Ru to Rd. Then with respect to this mapping, Ru is the
` "upstream LSR", and Rd is the "downstream LSR".
`
` The notion of upstream and downstream relate to agreements between
` nodes of the label values to be assigned for packets belonging to a
` particular Stream that might be traveling from an upstream node to a
` downstream node. This is independent of whether the routing protocol
` actually will cause any packets to be transmitted in that particular
` direction. Thus, Rd is the downstream LSR for a particular mapping
` for label L if it recognizes L-labeled packets from Ru as being in
` Stream S. This may be true even if routing does not actually forward
` packets for Stream S between nodes Rd and Ru, or if routing has made
` Ru downstream of Rd along the path which is actually used for packets
` in Stream S.
`
`2.3. Labeled Packet
`
` A "labeled packet" is a packet into which a label has been encoded.
` The encoding can be done by means of an encapsulation which exists
` specifically for this purpose, or by placing the label in an
` available location in either of the data link or network layer
` headers. Of course, the encoding technique must be agreed to by the
` entity which encodes the label and the entity which decodes the
` label.
`
`2.4. Label Assignment and Distribution; Attributes
`
` For unicast traffic in the MPLS architecture, the decision to bind a
` particular label L to a particular Stream S is made by the LSR which
` is downstream with respect to that mapping. The downstream LSR then
` informs the upstream LSR of the mapping. Thus labels are
` "downstream-assigned", and are "distributed upstream".
`
` A particular mapping of label L to Stream S, distributed by Rd to Ru,
` may have associated "attributes". If Ru, acting as a downstream LSR,
` also distributes a mapping of a label to Stream S, then under certain
`
`Rosen, Viswanathan & Callon [Page 11]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
` conditions, it may be required to also distribute the corresponding
` attribute that it received from Rd.
`
`2.5. Label Distribution Protocol (LDP)
`
` A Label Distribution Protocol (LDP) is a set of procedures by which
` one LSR informs another of the label/Stream mappings it has made.
` Two LSRs which use an LDP to exchange label/Stream mapping
` information are known as "LDP Peers" with respect to the mapping
` information they exchange; we will speak of there being an "LDP
` Adjacency" between them.
`
` (N.B.: two LSRs may be LDP Peers with respect to some set of
` mappings, but not with respect to some other set of mappings.)
`
` The LDP also encompasses any negotiations in which two LDP Peers need
` to engage in order to learn of each other’s MPLS capabilities.
`
`2.6. The Label Stack
`
` 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
` 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".
`
` At a particular LSR, the decision as to how to forward a labeled
` packet is always based exclusively on the label at the top of the
` stack.
`
` An unlabeled packet can be thought of as a packet whose label stack
` is empty (i.e., whose label stack has depth 0).
`
` If a packet’s label stack is of depth m, we refer to the label at the
` bottom of the stack as the level 1 label, to the label above it (if
` such exists) as the level 2 label, and to the label at the top of the
` stack as the level m label.
`
` The utility of the label stack will become clear when we introduce
` the notion of LSP Tunnel and the MPLS Hierarchy (sections 2.19.3 and
` 2.19.4).
`
`Rosen, Viswanathan & Callon [Page 12]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
`2.7. The Next Hop Label Forwarding Entry (NHLFE)
`
` The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding
` a labeled packet. It contains the following information:
`
` 1. the packet’s next hop
`
` 2. the data link encapsulation to use when transmitting the packet
`
` 3. the way to encode the label stack when transmitting the packet
`
` 4. the operation to perform on the packet’s label stack; this is
` one of the following operations:
`
` a) replace the label at the top of the label stack with a
` specified new label
`
` b) pop the label stack
`
` c) replace the label at the top of the label stack with a
` specified new label, and then push one or more specified
` new labels onto the label stack.
`
` Note that at a given LSR, the packet’s "next hop" might be that LSR
` itself. In this case, the LSR would need to pop the top level label
` and examine and operate on the encapsulated packet. This may be a
` lower level label, or may be the native IP packet. This implies that
` in some cases the LSR may need to operate on the IP header in order
` to forward the packet. If the packet’s "next hop" is the current LSR,
` then the label stack operation MUST be to "pop the stack".
`
`2.8. Incoming Label Map (ILM)
`
` The "Incoming Label Map" (ILM) is a mapping from incoming labels to
` NHLFEs. It is used when forwarding packets that arrive as labeled
` packets.
`
`2.9. Stream-to-NHLFE Map (STN)
`
` The "Stream-to-NHLFE" (STN) is a mapping from stream to NHLFEs. It is
` used when forwarding packets that arrive unlabeled, but which are to
` be labeled before being forwarded.
`
`Rosen, Viswanathan & Callon [Page 13]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
`2.10. Label Swapping
`
` Label swapping is the use of the following procedures to forward a
` packet.
`
` 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
` NHLFE. Using the information in the NHLFE, it determines where to
` forward the packet, and performs an operation on the packet’s label
` stack. It then encodes the new label stack into the packet, and
` forwards the result.
`
` In order to forward an unlabeled packet, a LSR analyzes the network
` layer header, to determine the packet’s Stream. It then uses the FTN
` to map this to an NHLFE. Using the information in the NHLFE, it
` determines where to forward the packet, and performs an operation on
` the packet’s label stack. (Popping the label stack would, of course,
` be illegal in this case.) It then encodes the new label stack into
` the packet, and forwards the result.
`
` 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
` different from what the next hop would be if MPLS were not in use.
`
`2.11. Label Switched Path (LSP), LSP Ingress, LSP Egress
`
` A "Label Switched Path (LSP) of level m" for a particular packet P is
` a sequence of LSRs,
`
` <R1, ..., Rn>
`
` with the following properties:
`
` 1. R1, the "LSP Ingress", pushes a label onto P’s label stack,
` resulting in a label stack of depth m;
`
` 2. For all i, 1<i<n, P has a label stack of depth m when received
` by Ri;
`
` 3. At no time during P’s transit from R1 to R[n-1] does its label
` stack ever have a depth of less than m;
`
` 4. For all i, 1<i<n: Ri transmits P to R[i+1] by means of MPLS,
` i.e., by using the label at the top of the label stack (the
` level m label) as an index into an ILM;
`
`Rosen, Viswanathan & Callon [Page 14]
`
`

`

`
`Internet Draft draft-rosen-mpls-arch-00.txt July 1997
`
` 5. For all i, 1<i<n: if a system S receives and forwards P after P
` is transmitted by Ri but before P is received by R[i+1] (e.g.,
` Ri and R[i+1] might be connected via a switched data link