GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3035

Network Working Group B. Davie Request for Comments: 3035 J. Lawrence Category: Standards Track K. McCloghrie

                                                              E. Rosen
                                                            G. Swallow
                                                   Cisco Systems, Inc.
                                                            Y. Rekhter
                                                      Juniper Networks
                                                             P. Doolan
                                               Ennovate Networks, Inc.
                                                          January 2001
                MPLS using LDP and ATM VC Switching

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

 The Multiprotocol Label Switching (MPLS) Architecture [1] discusses a
 way in which Asynchronous Transfer Mode (ATM) switches may be used as
 Label Switching Routers.  The ATM switches run network layer routing
 algorithms (such as Open Shortest Path First (OSPF), Intermediate
 System to Intermediate System (IS-IS), etc.), and their data
 forwarding is based on the results of these routing algorithms.  No
 ATM-specific routing or addressing is needed.  ATM switches used in
 this way are known as ATM-LSRs (Label Switching Routers).
 This document extends and clarifies the relevant portions of [1] and
 [2] by specifying in more detail the procedures which to be used when
 distributing labels to or from ATM-LSRs, when those labels represent
 Forwarding Equivalence Classes (FECs, see [1]) for which the routes
 are determined on a hop-by-hop basis by network layer routing
 algorithms.
 This document also specifies the MPLS encapsulation to be used when
 sending labeled packets to or from ATM-LSRs, and in that respect is a
 companion document to [3].

Davie Standards Track [Page 1] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

Table of Contents

  1      Introduction  ...........................................   2
  2      Specification of Requirements  ..........................   3
  3      Definitions  ............................................   3
  4      Special Characteristics of ATM Switches  ................   4
  5      Label Switching Control Component for ATM  ..............   5
  6      Hybrid Switches (Ships in the Night)  ...................   5
  7      Use of  VPI/VCIs  .......................................   5
  7.1    Direct Connections  .....................................   6
  7.2    Connections via an ATM VP  ..............................   7
  7.3    Connections via an ATM SVC  .............................   7
  8      Label Distribution and Maintenance Procedures  ..........   7
  8.1    Edge LSR Behavior  ......................................   8
  8.2    Conventional ATM Switches (non-VC-merge)  ...............   9
  8.3    VC-merge-capable ATM Switches  ..........................  11
  9      Encapsulation  ..........................................  12
 10      TTL Manipulation  .......................................  13
 11      Optional Loop Detection: Distributing Path Vectors  .....  15
 11.1    When to Send Path Vectors Downstream  ...................  15
 11.2    When to Send Path Vectors Upstream  .....................  16
 12      Security Considerations  ................................  17
 13      Intellectual Property Considerations  ...................  17
 14      References  .............................................  18
 15      Acknowledgments  ........................................  18
 16      Authors' Addresses  .....................................  18
 17      Full Copyright Statement  ...............................  20

1. Introduction

 The MPLS Architecture [1] discusses the way in which ATM switches may
 be used as Label Switching Routers.  The ATM switches run network
 layer routing algorithms (such as OSPF, IS-IS, etc.), and their data
 forwarding is based on the results of these routing algorithms. No
 ATM-specific routing or addressing is needed.  ATM switches used in
 this way are known as ATM-LSRs.
 This document extends and clarifies the relevant portions of [1] and
 [2] by specifying in more detail the procedures which are to be used
 for distributing labels to or from ATM-LSRs, when those labels
 represent Forwarding Equivalence Classes (FECs, see [1]) for which
 the routes are determined on a hop-by-hop basis by network layer
 routing algorithms.  The label distribution technique described here
 is referred to in [1] as "downstream-on-demand".  This label
 distribution technique MUST be used by ATM-LSRs that are not capable
 of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs
 that are capable of VC merge.

Davie Standards Track [Page 2] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 This document does NOT specify the label distribution techniques to
 be used in the following cases:
  1. the routes are explicitly chosen before label distribution

begins, instead of being chosen on a hop-by-hop basis as label

       distribution proceeds,
  1. the routes are intended to diverge in any way from the routes

chosen by the conventional hop-by-hop routing at any time,

  1. the labels represent FECs that consist of multicast packets,
  1. the LSRs use "VP merge".
 Further statements made in this document about ATM-LSR label
 distribution do not necessarily apply in these cases.
 This document also specifies the MPLS encapsulation to be used when
 sending labeled packets to or from ATM-LSRs, and in that respect is a
 companion document to [3].  The specified encapsulation is to be used
 for multicast or explicitly routed labeled packets as well.
 This document uses terminology from [1].

2. Specification of Requirements

 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.

3. Definitions

 A Label Switching Router (LSR) is a device which implements the label
 switching control and forwarding components described in [1].
 A label switching controlled ATM (LC-ATM) interface is an ATM
 interface controlled by the label switching control component.  When
 a packet traversing such an interface is received, it is treated as a
 labeled packet.  The packet's top label is inferred either from the
 contents of the VCI field or the combined contents of the VPI and VCI
 fields.  Any two LDP peers which are connected via an LC-ATM
 interface will use LDP negotiations to determine which of these cases
 is applicable to that interface.
 An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards
 cells between these interfaces, using labels carried in the VCI or
 VPI/VCI field, without reassembling the cells into frames before
 forwarding.

Davie Standards Track [Page 3] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 A frame-based LSR is a LSR which forwards complete frames between its
 interfaces.  Note that such a LSR may have zero, one or more LC-ATM
 interfaces.
 Sometimes a single box may behave as an ATM-LSR with respect to
 certain pairs of interfaces, but may behave as a frame-based LSR with
 respect to other pairs.  For example, an ATM switch with an ethernet
 interface may function as an ATM-LSR when forwarding cells between
 its LC-ATM interfaces, but may function as a frame-based LSR when
 forwarding frames from its ethernet to one of its LC-ATM interfaces.
 In such cases, one can consider the two functions (ATM-LSR and
 frame-based LSR) as being coresident in a single box.
 It is intended that an LC-ATM interface be used to connect two ATM-
 LSRs, or to connect an ATM-LSR to a frame-based LSR.  The use of an
 LC-ATM interface to connect two frame-based LSRs is not considered in
 this document.
 An ATM-LSR domain is a set of ATM-LSRs which are mutually
 interconnected by LC-ATM interfaces.
 The Edge Set of an ATM-LSR domain is the set of frame-based LSRs
 which are connected to members of the domain by LC-ATM interfaces.  A
 frame-based LSR which is a member of an Edge Set of an ATM-LSR domain
 may be called an Edge LSR.
 VC-merge is the process by which a switch receives cells on several
 incoming VCIs and transmits them on a single outgoing VCI without
 causing the cells of different AAL5 PDUs to become interleaved.

4. Special Characteristics of ATM Switches

 While the MPLS architecture permits considerable flexibility in LSR
 implementation, an ATM-LSR is constrained by the capabilities of the
 (possibly pre-existing) hardware and the restrictions on such matters
 as cell format imposed by ATM standards.  Because of these
 constraints, some special procedures are required for ATM-LSRs.
 Some of the key features of ATM switches that affect their behavior
 as LSRs are:
  1. the label swapping function is performed on fields (the VCI

and/or VPI) in the cell header; this dictates the size and

       placement of the label(s) in a packet.
  1. multipoint-to-point and multipoint-to-multipoint VCs are

generally not supported. This means that most switches cannot

       support 'VC-merge' as defined above.

Davie Standards Track [Page 4] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

  1. there is generally no capability to perform a 'TTL-decrement'

function as is performed on IP headers in routers.

 This document describes ways of applying label switching to ATM
 switches which work within these constraints.

5. Label Switching Control Component for ATM

 To support label switching an ATM switch MUST implement the control
 component of label switching.  This consists primarily of label
 allocation, distribution, and maintenance procedures.  Label binding
 information is communicated by several mechanisms, notably the Label
 Distribution Protocol (LDP) [2].  This document imposes certain
 requirements on the LDP.
 This document considers only the case where the label switching
 control component uses information learned directly from network
 layer routing protocols.  It is presupposed that the switch
 participates as a peer in these protocols (e.g., OSPF, IS-IS).
 In some cases, LSRs make use of other protocols (e.g., RSVP, PIM,
 BGP) to distribute label bindings.  In these cases, an ATM-LSR would
 need to participate in these protocols.  However, these are not
 explicitly considered in this document.
 Support of label switching on an ATM switch does NOT require the
 switch to support the ATM control component defined by the ITU and
 ATM Forum (e.g., UNI, PNNI).  An ATM-LSR may OPTIONALLY respond to
 OAM cells.

6. Hybrid Switches (Ships in the Night)

 The existence of the label switching control component on an ATM
 switch does not preclude the ability to support the ATM control
 component defined by the ITU and ATM Forum on the same switch and the
 same interfaces.  The two control components, label switching and the
 ITU/ATM Forum defined, would operate independently.
 Definition of how such a device operates is beyond the scope of this
 document.  However, only a small amount of information needs to be
 consistent between the two control components, such as the portions
 of the VPI/VCI space which are available to each component.

7. Use of VPI/VCIs

 Label switching is accomplished by associating labels with Forwarding
 Equivalence Classes, and using the label value to forward packets,
 including determining the value of any replacement label.  See [1]

Davie Standards Track [Page 5] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 for further details.  In an ATM-LSR, the label is carried in the
 VPI/VCI field, or, when two ATM-LSRs are connected via an ATM
 "Virtual Path", in the VCI field.
 Labeled packets MUST be transmitted using the null encapsulation, as
 defined in Section 6.1 of RFC 2684 [5].
 In addition, if two LDP peers are connected via an LC-ATM interface,
 a non-MPLS connection, capable of carrying unlabelled IP packets,
 MUST be available.  This non-MPLS connection is used to carry LDP
 packets between the two peers, and MAY also be used (but is not
 required to be used) for other unlabeled packets (such as OSPF
 packets, etc.).  The LLC/SNAP encapsulation of RFC 2684 [5] MUST be
 used on the non-MPLS connection.
 It SHOULD be possible to configure an LC-ATM interface with
 additional VPI/VCIs that are used to carry control information or
 non-labelled packets.  In that case, the VCI values MUST NOT be in
 the 0-32 range.  These may use either the null encapsulation, as
 defined in Section 6.1 of RFC 2684 [5], or the LLC/SNAP
 encapsulation, as defined in Section 5.1 of RFC 2684 [5].

7.1. Direct Connections

 We say that two LSRs are "directly connected" over an LC-ATM
 interface if all cells transmitted out that interface by one LSR will
 reach the other, and there are no ATM switches between the two LSRs.
 When two LSRs are directly connected via an LC-ATM interface, they
 jointly control the allocation of VPIs/VCIs on the interface
 connecting them.  They may agree to use the VPI/VCI field to encode a
 single label.
 The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI
 32.  Other values can be configured, as long as both parties are
 aware of the configured value.
 A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST
 NOT be used as the encoding of a label.
 With the exception of these reserved values, the VPI/VCI values used
 in the two directions of the link MAY be treated as independent
 spaces.
 The allowable ranges of VCIs are communicated through LDP.

Davie Standards Track [Page 6] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

7.2. Connections via an ATM VP

 Sometimes it can be useful to treat two LSRs as adjacent (in some
 LSP) across an LC-ATM interface, even though the connection between
 them is made through an ATM "cloud" via an ATM Virtual Path.  In this
 case, the VPI field is not available to MPLS, and the label MUST be
 encoded entirely within the VCI field.
 In this case, the default VCI value of the non-MPLS connection
 between the LSRs is 32.  Other values can be configured, as long as
 both parties are aware of the configured value.  The VPI is set to
 whatever is required to make use of the Virtual Path.
 A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST
 NOT be used as the encoding of a label.
 With the exception of these reserved values, the VPI/VCI values used
 in the two directions of the link MAY be treated as independent
 spaces.
 The allowable ranges of VPI/VCIs are communicated through LDP.  If
 more than one VPI is used for label switching, the allowable range of
 VCIs may be different for each VPI, and each range is communicated
 through LDP.

7.3. Connections via an ATM SVC

 Sometimes it may be useful to treat two LSRs as adjacent (in some
 LSP) across an LC-ATM interface, even though the connection between
 them is made through an ATM "cloud" via a set of ATM Switched Virtual
 Circuits.
 The current document does not specify the procedure for handling this
 case.  Such procedures can be found in [4].  The procedures described
 in [4] allow a VCID to be assigned to each such VC, and specify how
 LDP can be used used to bind a VCID to a FEC.  The top label of a
 received packet would then be inferred (via a one-to-one mapping)
 from the virtual circuit on which the packet arrived.  There would
 not be a default VPI or VCI value for the non-MPLS connection.

8. Label Distribution and Maintenance Procedures

 This document discusses the use of "downstream-on-demand" label
 distribution (see [1]) by ATM-LSRs.  These label distribution
 procedures MUST be used by ATM-LSRs that do not support VC-merge, and
 MAY also be used by ATM-LSRs that do support VC-merge.  The
 procedures differ somewhat in the two cases, however.  We therefore
 describe the two scenarios in turn.  We begin by describing the

Davie Standards Track [Page 7] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 behavior of members of the Edge Set of an ATM-LSR domain; these "Edge
 LSRs" are not themselves ATM-LSRs, and their behavior is the same
 whether the domain contains VC-merge capable LSRs or not.

8.1. Edge LSR Behavior

 Consider a member of the Edge Set of an ATM-LSR domain.  Assume that,
 as a result of its routing calculations, it selects an ATM-LSR as the
 next hop of a certain FEC, and that the next hop is reachable via a
 LC-ATM interface.  The Edge LSR uses LDP to request a label binding
 for that FEC from the next hop.  The hop count field in the request
 is set to 1 (but see the next paragraph).  Once the Edge LSR receives
 the label binding information, it may use MPLS forwarding procedures
 to transmit packets in the specified FEC, using the specified label
 as an outgoing label.  (Or using the VPI/VCI that corresponds to the
 specified VCID as the outgoing label, if the VCID technique of [4] is
 being used.)
 Note: if the Edge LSR's previous hop is using downstream-on-demand
 label distribution to request a label from the Edge LSR for a
 particular FEC, and if the Edge LSR is not merging the LSP from that
 previous hop with any other LSP, and if the request from the previous
 hop has a hop count of h, then the hop count in the request issued by
 the Edge LSR should not be set to 1, but rather to h+1.
 The binding received by the edge LSR may contain a hop count, which
 represents the number of hops a packet will take to cross the ATM-LSR
 domain when using this label.  If there is a hop count associated
 with the binding, the ATM-LSR SHOULD adjust a data packet's TTL by
 this amount before transmitting the packet.  In any event, it MUST
 adjust a data packet's TTL by at least one before transmitting it.
 The procedures for doing so (in the case of IP packets) are specified
 in section 10.  The procedures for encapsulating the packets are
 specified in section 9.
 When a member of the Edge Set of the ATM-LSR domain receives a label
 binding request from an ATM-LSR, it allocates a label, and returns
 (via LDP) a binding containing the allocated label back to the peer
 that originated the request.  It sets the hop count in the binding to
 1.
 When a routing calculation causes an Edge LSR to change the next hop
 for a particular FEC, and the former next hop was in the ATM-LSR
 domain, the Edge LSR SHOULD notify the former next hop (via LDP) that
 the label binding associated with the FEC is no longer needed.

Davie Standards Track [Page 8] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

8.2. Conventional ATM Switches (non-VC-merge)

 When an ATM-LSR receives (via LDP) a label binding request for a
 certain FEC from a peer connected to the ATM-LSR over a LC-ATM
 interface, the ATM-LSR takes the following actions:
  1. it allocates a label,
  1. it requests (via LDP) a label binding from the next hop for

that FEC;

  1. it returns (via LDP) a binding containing the allocated

incoming label back to the peer that originated the request.

 For purposes of this procedure, we define a maximum hop count value
 MAXHOP.  MAXHOP has a default value of 255, but may be configured to
 a different value.
 The hop count field in the request that the ATM-LSR sends (to the
 next hop LSR) MUST be set to one more than the hop count field in the
 request that it received from the upstream LSR.  If the resulting hop
 count exceeds MAXHOP, the request MUST NOT be sent to the next hop,
 and the ATM-LSR MUST notify the upstream neighbor that its binding
 request cannot be satisfied.
 Otherwise, once the ATM-LSR receives the binding from the next hop,
 it begins using that label.
 The ATM-LSR MAY choose to wait for the request to be satisfied from
 downstream before returning the binding upstream.  This is a form of
 "ordered control" (as defined in [1] and [2]), in particular
 "ingress-initiated ordered control".  In this case, as long as the
 ATM-LSR receives from downstream a hop count which is greater than 0
 and less than MAXHOP, it MUST increment the hop count it receives
 from downstream and MUST include the result in the binding it returns
 upstream.  However, if the hop count exceeds MAXHOP, a label binding
 MUST NOT be passed upstream.  Rather, the upstream LDP peer MUST be
 informed that the requested label binding cannot be satisfied.  If
 the hop count received from downstream is 0, the hop count passed
 upstream should also be 0; this indicates that the actual hop count
 is unknown.
 Alternatively, the ATM-LSR MAY return the binding upstream without
 waiting for a binding from downstream ("independent" control, as
 defined in [1] and [2]).  In this case, it specifies a hop count of 0
 in the binding, indicating that the true hop count is unknown.  The
 correct value for hop count will be returned later, as described
 below.

Davie Standards Track [Page 9] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 Note that an ATM-LSR, or a member of the edge set of an ATM-LSR
 domain, may receive multiple binding requests for the same FEC from
 the same ATM-LSR.  It MUST generate a new binding for each request
 (assuming adequate resources to do so), and retain any existing
 binding(s).  For each request received, an ATM-LSR MUST also generate
 a new binding request toward the next hop for the FEC.
 When a routing calculation causes an ATM-LSR to change the next hop
 for a FEC, the ATM-LSR MUST notify the former next hop (via LDP) that
 the label binding associated with the FEC is no longer needed.
 When a LSR receives a notification that a particular label binding is
 no longer needed, the LSR MAY deallocate the label associated with
 the binding, and destroy the binding.  In the case where an ATM-LSR
 receives such notification and destroys the binding, it MUST notify
 the next hop for the FEC that the label binding is no longer needed.
 If a LSR does not destroy the binding, it may re-use the binding only
 if it receives a request for the same FEC with the same hop count as
 the request that originally caused the binding to be created.
 When a route changes, the label bindings are re-established from the
 point where the route diverges from the previous route.   LSRs
 upstream of that point are (with one exception, noted below)
 oblivious to the change.
 Whenever a LSR changes its next hop for a particular FEC, if the new
 next hop is reachable via an LC-ATM interface, then for each label
 that it has bound to that FEC, and distributed upstream, it MUST
 request a new label binding from the new next hop.
 When an ATM-LSR receives a label binding for a particular FEC from a
 downstream neighbor, it may already have provided a corresponding
 label binding for this FEC to an upstream neighbor, either because it
 is using independent control, or because the new binding from
 downstream is the result of a routing change.  In this case, unless
 the hop count is 0, it MUST extract the hop count from the new
 binding and increment it by one.  If the new hop count is different
 from that which was previously conveyed to the upstream neighbor
 (including the case where the upstream neighbor was given the value
 'unknown') the ATM-LSR MUST notify the upstream neighbor of the
 change.  Each ATM-LSR in turn MUST increment the hop count and pass
 it upstream until it reaches the ingress Edge LSR.  If at any point
 the value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw
 the binding from the upstream neighbor.  A hop count of 0 MUST be
 passed upstream unchanged.

Davie Standards Track [Page 10] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 Whenever an ATM-LSR originates a label binding request to its next
 hop LSR as a result of receiving a label binding request from another
 (upstream) LSR, and the request to the next hop LSR is not satisfied,
 the ATM-LSR SHOULD destroy the binding created in response to the
 received request, and notify the requester (via LDP).
 If an ATM-LSR receives a binding request containing a hop count that
 exceeds MAXHOP, it MUST not establish a binding, and it MUST return
 an error to the requester.
 When a LSR determines that it has lost its LDP session with another
 LSR, the following actions are taken.  Any binding information
 learned via this connection MUST be discarded.  For any label
 bindings that were created as a result of receiving label binding
 requests from the peer, the LSR MAY destroy these bindings (and
 deallocate labels associated with these binding).
 An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding
 requests from its neighbors.  That is, if it receives a request for a
 binding to a particular FEC and the LSR making that request is,
 according to this ATM-LSR, the next hop for that FEC, it should not
 return a binding for that route.
 It is expected that non-merging ATM-LSRs would generally use
 "conservative label retention mode" [1].

8.3. VC-merge-capable ATM Switches

 Relatively minor changes are needed to accommodate ATM-LSRs which
 support VC-merge.  The primary difference is that a VC-merge-capable
 ATM-LSR needs only one outgoing label per FEC, even if multiple
 requests for label bindings to that FEC are received from upstream
 neighbors.
 When a VC-merge-capable ATM-LSR receives a binding request from an
 upstream LSR for a certain FEC, and it does not already have an
 outgoing label binding for that FEC (or an outstanding request for
 such a label binding), it MUST issue a bind request to its next hop
 just as it would do if it were not merge-capable.  If, however, it
 already has an outgoing label binding for that FEC, it does not need
 to issue a downstream binding request.  Instead, it may simply
 allocate an incoming label, and return that label in a binding to the
 upstream requester.  When packets with that label as top label are
 received from the requester, the top label value will be replaced
 with the existing outgoing label value that corresponds to the same
 FEC.

Davie Standards Track [Page 11] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 If the ATM-LSR does not have an outgoing label binding for the FEC,
 but does have an outstanding request for one, it need not issue
 another request.
 When sending a label binding upstream, the hop count associated with
 the corresponding binding from downstream MUST be incremented by 1,
 and the result transmitted upstream as the hop count associated with
 the new binding.  However, there are two exceptions: a hop count of 0
 MUST be passed upstream unchanged, and if the hop count is already at
 MAXHOP, the ATM-LSR MUST NOT pass a binding upstream, but instead
 MUST send an error upstream.
 Note that, just like conventional ATM-LSRs and members of the edge
 set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue a
 new binding every time it receives a request from upstream, since
 there may be switches upstream which do not support VC-merge.
 However, it only needs to issue a corresponding binding request
 downstream if it does not already have a label binding for the
 appropriate route.
 When a change in the routing table of a VC-merge-capable ATM-LSR
 causes it to select a new next hop for one of its FECs, it MAY
 optionally release the binding for that route from the former next
 hop.  If it doesn't already have a corresponding binding for the new
 next hop, it must request one.  (The choice between conservative and
 liberal label retention mode [1] is an implementation option.)
 If a new binding is obtained, which contains a hop count that differs
 from that which was received in the old binding, then the ATM-LSR
 must take the new hop count, increment it by one, and notify any
 upstream neighbors who have label bindings for this FEC of the new
 value.  Just as with conventional ATM-LSRs, this enables the new hop
 count to propagate back towards the ingress of the ATM-LSR domain.
 If at any point the hop count exceeds MAXHOP, then the label bindings
 for this route must be withdrawn from all upstream neighbors to whom
 a binding was previously provided.  This ensures that any loops
 caused by routing transients will be detected and broken.

9. Encapsulation

 The procedures described in this section affect only the Edge LSRs of
 the ATM-LSR domain.  The ATM-LSRs themselves do not modify the
 encapsulation in any way.
 Labeled packets MUST be transmitted using the null encapsulation of
 Section 6.1 of RFC 2684 [5].

Davie Standards Track [Page 12] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 Except in certain circumstances specified below, when a labeled
 packet is transmitted on an LC-ATM interface, where the VPI/VCI (or
 VCID) is interpreted as the top label in the label stack, the packet
 MUST also contain a "shim header" [3].
 If the packet has a label stack with n entries, it MUST carry a shim
 with n entries.  The actual value of the top label is encoded in the
 VPI/VCI field.  The label value of the top entry in the shim (which
 is just a "placeholder" entry) MUST be set to 0 upon transmission,
 and MUST be ignored upon reception.  The packet's outgoing TTL, and
 its CoS, are carried in the TTL and CoS fields respectively of the
 top stack entry in the shim.
 Note that if a packet has a label stack with only one entry, this
 requires it to have a single-entry shim (4 bytes), even though the
 actual label value is encoded into the VPI/VCI field.  This is done
 to ensure that the packet always has a shim.  Otherwise, there would
 be no way to determine whether it had one or not, i.e., no way to
 determine whether there are additional label stack entries.
 The only ways to eliminate this extra overhead are:
  1. through apriori knowledge that packets have only a single label

(e.g., perhaps the network only supports one level of label)

  1. by using two VCs per FEC, one for those packets which have only

a single label, and one for those packets which have more than

       one label
 The second technique would require that there be some way of
 signalling via LDP that the VC is carrying only packets with a single
 label, and is not carrying a shim.  When supporting VC merge, one
 would also have to take care not to merge a VC on which the shim  is
 not used into a VC on which it is used, or vice versa.
 While either of these techniques is permitted, it is doubtful that
 they have any practical utility.  Note that if the shim header is not
 present, the outgoing TTL is carried in the TTL field of the network
 layer header.

10. TTL Manipulation

 The procedures described in this section affect only the Edge LSRs of
 the ATM-LSR domain.  The ATM-LSRs themselves do not modify the TTL in
 any way.

Davie Standards Track [Page 13] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 The details of the TTL adjustment procedure are as follows.  If a
 packet was received by the Edge LSR as an unlabeled packet, the
 "incoming TTL" comes from the IP header.  (Procedures for other
 network layer protocols are for further study.) If a packet was
 received by the Edge LSR as a labeled packet, using the encapsulation
 specified in [3], the "incoming TTL" comes from the entry at the top
 of the label stack.
 If a hop count has been associated with the label binding that is
 used when the packet is forwarded, the "outgoing TTL" is set to the
 larger of (a) 0 or (b) the difference between the incoming TTL and
 the hop count.  If a hop count has not been associated with the label
 binding that is used when the packet is forwarded, the "outgoing TTL"
 is set to the larger of (a) 0 or (b) one less than the incoming TTL.
 If this causes the outgoing TTL to become zero, the packet MUST NOT
 be transmitted as a labeled packet using the specified label.  The
 packet can be treated in one of two ways:
  1. it may be treated as having expired; this may cause an ICMP

message to be transmitted;

  1. the packet may be forwarded, as an unlabeled packet, with a TTL

that is 1 less than the incoming TTL; such forwarding would

       need to be done over a non-MPLS connection.
 Of course, if the incoming TTL is 1, only the first of these two
 options is applicable.
 If the packet is forwarded as a labeled packet, the outgoing TTL is
 carried as specified in section 9.
 When an Edge LSR receives a labeled packet over an LC-ATM interface,
 it obtains the incoming TTL from the top label stack entry of the
 generic encapsulation, or, if that encapsulation is not present, from
 the IP header.
 If the packet's next hop is an ATM-LSR, the outgoing TTL is formed
 using the procedures described in this section.  Otherwise the
 outgoing TTL is formed using the procedures described in [3].
 The procedures in this section are intended to apply only to unicast
 packets.

Davie Standards Track [Page 14] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

11. Optional Loop Detection: Distributing Path Vectors

 Every ATM-LSR MUST implement, as a configurable option, the following
 procedure for detecting forwarding loops.  We refer to this as the
 LDPV (Loop Detection via Path Vectors) procedure.  This procedure
 does not prevent the formation of forwarding loops, but does ensure
 that any such loops are detected.  If this option is not enabled,
 loops are detected by the hop count mechanism previously described.
 If this option is enabled, loops will be detected more quickly, but
 at a higher cost in overhead.

11.1. When to Send Path Vectors Downstream

 Suppose an LSR R sends a request for a label binding, for a
 particular LSP, to its next hop.  Then if R does not support VC-
 merging, and R is configured to use the LDPV procedure:
  1. If R is sending the request because it is an ingress node for

that LSP, or because it has acquired a new next hop, then R

       MUST include a path vector object with the request, and the
       path vector object MUST contain only R's own address.
  1. If R is sending the request as a result of having received a

request from an upstream LSR, then:

  • if the received request has a path vector object, R MUST add

its own address to the received path vector object, and MUST

          pass the resulting path vector object to its next hop along
          with the label binding request;
  • if the received request does not have a path vector object,

R MUST include a path vector object with the request it

          sends, and the path vector object MUST contain only R's own
          address.
 An LSR which supports VC-merge SHOULD NOT include a path vector
 object in the requests that it sends to its next hop.
 If an LSR receives a label binding request whose path vector object
 contains the address of the node itself, the LSR concludes that the
 label binding requests have traveled in a loop.  The LSR MUST act as
 it would in the case where the hop count exceeds MAXHOP (see section
 8.2).
 This procedure detects the case where the request messages loop
 though a sequence of non-merging ATM-LSRs.

Davie Standards Track [Page 15] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

11.2. When to Send Path Vectors Upstream

 As specified in section 8, there are circumstances in which an LSR R
 must inform its upstream neighbors, via a label binding response
 message, of a change in hop count for a particular LSP.  If the
 following conditions all hold:
  1. R is configured for the LDPV procedure,
  1. R supports VC-merge,
  1. R is not the egress for that LSP, and
  1. R is not informing its neighbors of a decrease in the hop

count,

 then R MUST include a path vector object in the response message.
 If the change in hop count is a result of R's having been informed by
 its next hop, S, of a change in hop count, and the message from S to
 R included a path vector object, then if the above conditions hold, R
 MUST add itself to this object and pass the result upstream.
 Otherwise, if the above conditions hold, R MUST create a new object
 with only its own address.
 If R is configured for the LDPV procedure, and R supports VC merge,
 then it MAY include a path vector object in any label binding
 response message that it sends upstream.  In particular, at any time
 that R receives a label binding response from its next hop, if that
 response contains a path vector, R MAY (if configured for the LDPV
 procedure) send a response to its upstream neighbors, containing the
 path vector object formed by adding its own address to the received
 path vector.
 If R does not support VC merge, it SHOULD NOT send a path vector
 object upstream.
 If an LSR  receives a message from  its next hop, with a  path vector
 object containing its own address, then  LSR  MUST act as it would if
 it received a message with a hop count equal to MAXHOP.
 LSRs which are configured for the LDPV procedure SHOULD NOT store a
 path vector once the corresponding path vector object has been
 transmitted.

Davie Standards Track [Page 16] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 Note that if the ATM-LSR domain consists entirely of non-merging
 ATM-LSRs, path vectors need not ever be sent upstream, since any
 loops will be detected by means of the path vectors traveling
 downstream.
 By not sending path vectors unless the hop count increases, one
 avoids sending them in many situations when there is no loop.  The
 cost is that in some situations in which there is a loop, the time to
 detect the loop may be lengthened.

12. Security Considerations

 The encapsulation and procedures specified in this document do not
 interfere in any way with the application of authentication and/or
 encryption to network layer packets (such as the application of IPSEC
 to IP datagrams).
 The procedures described in this document do not protect against the
 alteration (either accidental or malicious) of MPLS labels.  Such
 alteration could cause misforwarding.
 The procedures described in this document do not enable a receiving
 LSR to authenticate the transmitting LSR.
 A discussion of the security considerations applicable to the label
 distribution mechanism can be found in [2].

13. Intellectual Property Considerations

 The IETF has been notified of intellectual property rights claimed in
 regard to some or all of the specification contained in this
 document.  For more information consult the online list of claimed
 rights.
 The IETF takes no position regarding the validity or scope of any
 intellectual property or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; neither does it represent that it
 has made any effort to identify any such rights.  Information on the
 IETF's procedures with respect to rights in standards-track and
 standards-related documentation can be found in BCP-11.  Copies of
 claims of rights made available for publication and any assurances of
 licenses to be made available, or the result of an attempt made to
 obtain a general license or permission for the use of such
 proprietary rights by implementors or users of this specification can
 be obtained from the IETF Secretariat.

Davie Standards Track [Page 17] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights which may cover technology that may be required to practice
 this standard.  Please address the information to the IETF Executive
 Director.

14. References

 [1] Rosen, E., Viswanathan, A. and R. Callon "Multi-Protocol Label
     Switching Architecture", RFC 3031, January 2001.
 [2] Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas,
     "LDP Specification", RFC 3036, January 2001.
 [3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G.,
     Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
     January 2001.
 [4] Nagami, K., Demizu N., Esaki H. and P. Doolan, "VCID Notification
     over ATM Link for LDP", RFC 3038, January 2001.
 [5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM
     Adaptation Layer 5", RFC 2684, September 1999.

15. Acknowledgments

 Significant contributions to this work have been made by Anthony
 Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan
 Littlewood and Dan Tappan.  We thank Alex Conta for his comments.

16. Authors' Addresses

 Bruce Davie
 Cisco Systems, Inc.
 250 Apollo Drive
 Chelmsford, MA, 01824
 EMail: bsd@cisco.com
 Paul Doolan
 Ennovate Networks Inc.
 60 Codman Hill Rd
 Boxborough, MA 01719
 EMail: pdoolan@ennovatenetworks.com

Davie Standards Track [Page 18] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

 Jeremy Lawrence
 Cisco Systems, Inc.
 99 Walker St.
 North Sydney, NSW, Australia
 EMail: jlawrenc@cisco.com
 Keith McCloghrie
 Cisco Systems, Inc.
 170 Tasman Drive
 San Jose, CA, 95134
 EMail: kzm@cisco.com
 Yakov Rekhter
 Juniper Networks
 1194 N. Mathilda Avenue
 Sunnyvale, CA 94089
 EMail: yakov@juniper.net
 Eric Rosen
 Cisco Systems, Inc.
 250 Apollo Drive
 Chelmsford, MA, 01824
 EMail: erosen@cisco.com
 George Swallow
 Cisco Systems, Inc.
 250 Apollo Drive
 Chelmsford, MA, 01824
 EMail: swallow@cisco.com

Davie Standards Track [Page 19] RFC 3035 MPLS using LDP and ATM VC Switching January 2001

17. Full Copyright Statement

 Copyright (C) The Internet Society (2001).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Davie Standards Track [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3035.txt · Last modified: 2001/01/05 18:32 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki