<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.mpls-seamless-mpls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-seamless-mpls.xml">
<!ENTITY I-D.ietf-mpls-ldp-ipv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-ldp-ipv6.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-beckhaus-ldp-dod-00" ipr="trust200902">
  <front>
    <title abbrev="">LDP Downstream-on-Demand in Seamless MPLS</title>

    <author fullname="Thomas Beckhaus" initials="T" surname="Beckhaus">
      <organization>Deutsche Telekom AG</organization>

      <address>
        <postal>
          <street>Heinrich-Hertz-Strasse 3-7</street>

          <city>Darmstadt</city>

          <region></region>

          <code>64307</code>

          <country>Germany</country>
        </postal>

        <phone>+49 6151 58 12825</phone>

        <facsimile></facsimile>

        <email>thomas.beckhaus@telekom.de</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="Bruno Decraene" initials="B" surname="Decraene">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street>38-40 rue du General Leclerc</street>

          <city>Issy Moulineaux cedex 9</city>

          <region></region>

          <code>92794</code>

          <country>France</country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>bruno.decraene@orange-ftgroup.com</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="Kishore Tiruveedhula" initials="K"
            surname="Tiruveedhula">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>10 Technology Park Drive</street>

          <city>Westford</city>

          <region>Massachusetts</region>

          <code>01886</code>

          <country>USA</country>
        </postal>

        <phone>1-(978)-589-8861</phone>

        <facsimile></facsimile>

        <email>kishoret@juniper.net</email>

        <uri></uri>
      </address>
    </author>

    <author fullname="Maciek Konstantynowicz" initials="M"
            surname="Konstantynowicz">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>maciek@juniper.net</email>

        <uri></uri>
      </address>
    </author>

    <date day="4" month="July" year="2011" />

    <abstract>
      <t>Seamless MPLS design enables a single IP/MPLS network to scale over
      core, metro and access parts of a large network infrastructure using
      standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is
      to meet requirements specific to access devices, based on their position
      in the network topology and their compute and memory constraints limit
      the amount of state they can hold. This can be achieved with LDP
      Downstream-on-Demand (LDP DoD) as specified in <xref
      target="RFC5036">RFC 5036</xref>. This document describes LDP DoD use
      cases and lists LDP DoD procedures in the context of Seamless MPLS
      design.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Seamless MPLS design enables a single IP/MPLS network to scale over
      core, metro and access parts of a large network infrastructure using
      standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is
      to meet requirements specific to access devices, based on their position
      in the network topology and their compute and memory constraints limit
      the amount of state they can hold. This can be achieved with LDP
      Downstream-on-Demand (LDP DoD) as specified in <xref
      target="RFC5036">RFC 5036</xref>. This document describes LDP DoD use
      cases and lists LDP DoD procedures in the context of Seamless MPLS
      design.</t>

      <t>In Seamless MPLS topologies described in [seamless-mpls] , IP/MPLS
      protocol optimization is possible due to a relatively simple network
      topology that access nodes (AN) are part of.</t>

      <t>AN connectivity options include:</t>

      <t><list style="symbols">
          <t hangText="">AN single-homed to an aggregation node (AGN)<list
              style="symbols">
              <t>with single link</t>

              <t>with multiple parallel links (IP ECMP or L2 LAG)</t>
            </list></t>

          <t>AN dual-homed to two AGNs<list style="symbols">
              <t>with single link</t>

              <t>with multiple parallel links (IP ECMP or L2 LAG)</t>
            </list></t>

          <t>AN daisy-chained via hub-AN<list style="symbols">
              <t>with single link</t>

              <t>with multiple parallel links (IP ECMP or L2 LAG)</t>
            </list></t>
        </list>With such topologies AN can implement the simplest IP routing
      configuration with static routes, limiting number of IP RIB and FIB
      entries required on AN. Furthermore MPLS label assignment can be
      addressed with LDP Downstream-on-Demand (LDP DoD) distribution. In
      general MPLS routers implement LDP Downstream Unsolicited (LDP DU) label
      distribution, advertising MPLS labels for all routes in their RIB. This
      is seen as very insufficient as ANs only require a small subset of total
      routes (and associated labels). LDP DoD enables on-request label
      distribution ensuring that only required labels are requested, provided
      and installed. Note that LDP DoD implementation is not widely available
      in today&rsquo;s IP/MPLS devices despite the fact that it has been
      described in the original LDP specification <xref target="RFC5036">RFC
      5036</xref>. This is because the original LDP DoD specification has been
      mainly used for ATM and FR&ndash;based MPLS LSRs in order to conserve
      available label space (i.e. with labels encoded in VPI/VCI).</t>
    </section>

    <section title="Reference Topologies">
      <t>Following reference end to end network topology is used for review
      the LDP DoD use cases based on Seamless MPLS <xref
      target="I-D.ietf-mpls-seamless-mpls"></xref>:</t>

      <t><figure>
          <artwork><![CDATA[              +-------+   +-------+   +------+   +------+
              |       |   |       |   |      |   |      |
           +--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
          /   |       |  /|       |   |      |   |      |
   +----+/    +-------+\/ +-------+   +------+  /+------+
   | AN |              /\                     \/
   +----+\    +-------+  \+-------+   +------+/\ +------+
          \   |       |   |       |   |      |  \|      |
           +--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
              |       |   |       |   |      |   |      |
              +-------+   +-------+   +------+   +------+

   static route     ISIS L1 LDP             ISIS L2 LDP

   <-Access-><--Aggregation Domain--><---------Core--------->
]]></artwork>

          <postamble>Figure 1. End-to-end reference network
          topology.</postamble>
        </figure></t>

      <t>Access Node is either single or dual homed to AGN1(s), with either a
      single or multiple parallel links to AGN1(s). AN has an LDP DoD session
      configured between its loopback address and the loopback address(es) of
      AGN1s. The reference AN configuration is shown in figure below.</t>

      <t><figure>
          <artwork><![CDATA[           +----+                        +-------+
           |    +------------------------+       +-------
           |AN1 |                        | AGN11 |
           |    +-------\    /-----------+       +-\    /
           +----+        \  /            +-------+  \  /
                          \/                         \/
                          /\                         /\
           +----+        /  \            +-------+  /  \
           |    +-------/    \-----------+       +-/    \
           |AN2 |                        | AGN12 |
           |    +------------------------+       +-------
           +----+                        +-------+
        
           --(a)->                        <-(b)--
        
        (a) static route 0/0 default (/32 destinations optional)
        (b) static route for /32 AN loopback
        
              <----------LDP DoD-----------> <--LDP DU-->
]]></artwork>

          <postamble>Figure 2. Dual-homed AN topology.</postamble>
        </figure></t>

      <t>A variant of AN topology is daisy-chained ANs shown in figure
      below:</t>

      <t><figure>
          <artwork><![CDATA[                                           +-------+
                                           |       |---/
                                      /----+ AGN11 |
        +----+   +----+   +----+     /     |       |---\
        |    |   |    |   |    +----/      +-------+
        |ANn +...|AN2 +---+AN1 |                    
        |    |   |    |   |    +----\      +-------+
        +----+   +----+   +----+     \     |       |---/
                                      \----+ AGN12 |
                <-(a)--   <-(b)--          |       |---\
        --(d)-> --(d)->   --(d)->          +-------+
                                           
                                           <-(c)--
        
        (a) static routes for /32 AN loopbacks 3..n
        (b) static routes for /32 AN loopbacks 2..n
        (c) static routes for /32 AN loopbacks 1..n
        (d) static routes 0/0 default, (/32 destinations optional)
        
          <------------LDP DoD----------------> <--LDP DU-->]]></artwork>

          <postamble>Figure 3. Daisy-chained AN topology.</postamble>
        </figure></t>

      <t>Access Node has at least following routing entries configured:<list
          style="symbols">
          <t>Static default routes (0.0.0.0/0) pointing to all interfaces
          linking to AGN1 nodes, one per interface.</t>

          <t>Specific static routes for /32 loopback address of the directly
          connected AGN1, pointing to all interfaces linked to this AGN1.</t>
        </list></t>

      <t>If AN does not support <xref target="RFC5283">RFC 5283</xref> and LDP
      label acceptance based on the longest match in the RIB, specific static
      routes to all required /32 destinations will be configured on this AN.
      This configuration is service dependent: every unique destination
      requires a distinct /32 static routing entry pointing to interfaces
      linking to AGN1 nodes.</t>

      <t>AGN1s have specific /32 static routes for adjacent AN&rsquo;s
      loopback address, pointing to all interfaces linked to this AN. If
      interfaces to AN are up, AGN1 advertises this /32 FEC over LDP
      Downstream Unsolicited (LDP DU) sessions to AGN2s.</t>

      <t>Note: Additional LDP features should be supported to comply with
      Seamless MPLS fast service restoration requirements as follows:<list
          style="symbols">
          <t>AN should support local-repair in case of AGN1 uplink or AGN1
          failure, by using either LDP LFA or simple ECMP or primary/backup
          switchover.</t>

          <t>AGN1 should support local-repair in case of AN downlink failure,
          by implementing IGP LFA (w/ LDP support).</t>

          <t>AGN should be configured with LDP-IGP synchronization to avoid
          traffic loss where there is no LDP label allocated to the downstream
          best IGP next hop.</t>

          <t>AN and AGN should be configured with LDP session protection to
          avoid delay upon the recovery from link failure.</t>
        </list></t>
    </section>

    <section title="LDP DoD Use Cases">
      <t>LDP DoD operation is driven by Seamless MPLS use cases. This section
      describes these use cases focusing on services provisioned on Access
      Node and required LDP DoD operation on AN and AGN. For simplicity an
      example of MPLS PWE3 service is used to illustrate the service use
      cases.</t>

      <t>Described LDP DoD operations apply equally to ANs connected over
      single links or parallel links (IP ECMP or L2 LAG).</t>

      <t>This document is focusing on IPv4 LDP DoD procedures. Similar
      procedures are required with IPv6 LDP DoD, however some extension
      specific to IPv6 will apply including LSP mapping, peer discovery,
      transport connection establishment. These will be added in this document
      once LDP IPv6 standardization is advanced as per <xref
      target="I-D.ietf-mpls-ldp-ipv6"></xref>.</t>

      <section title="Access Node Start-Up">
        <t>Access Node (AN) is commissioned without any service provisioned.
        AN may request labels for loopback addresses of AGN1, AGN2 or other
        nodes within Seamless MPLS. During the initial AN configuration no
        services are provisioned on it. It is assumed that AGN1 has required
        IP/MPLS configuration for network-side connectivity.</t>

        <t>AN is only provisioned with the following static IP routing
        entries:</t>

        <t><list style="symbols">
            <t>Static default route 0/0 pointing to interfaces connected to
            AGN1 (AGN11 and AGN12 if present).</t>

            <t>Static route for adjacent AGN1&rsquo;s loopback, pointing to
            interfaces connected to AGN1.</t>

            <t>(Optional) Static route for local metro AGN2&rsquo;s loopback,
            pointing to interfaces connected to AGN1.</t>

            <t>(Optional) Static routes for other nodes within Seamless MPLS
            network.</t>
          </list></t>

        <t>Note: last two entries are optional and not required if AN supports
        inter-area LDP <xref target="RFC5283">RFC 5283</xref> and triggering
        of LDP DoD label mapping request by service (e.g. PW)
        configuration.</t>

        <t>IP/MPLS configuration on AN includes LDP sessions to loopback
        addresses of adjacent AGN1&rsquo;s. Source IP address for this LDP
        session is the loopback address of AN.</t>

        <t>AGN1 is provisioned with a static route for AN's loopback, pointing
        to the interface connected to this AN. When the interface and link are
        up, AGN1 advertises this AN's static route into network side routing
        protocols i.e. IGP and/or MP-BGP Labeled Unicast.</t>

        <t>Access Node SHOULD request labels over LDP DoD session(s) to
        AGN1(s) for all configured static routes if this static routes are
        configured with LDP DoD request policy. It is expected that all /32
        static routes will be configured with such policy.</t>

        <t>AGN1 provides AN with requested labels and MUST install the labels
        in its label table (LIB) and its forwarding table (LFIB). Access Node
        MUST also install the labels in its LIB and LFIB.</t>
      </section>

      <section title="Access Node Service Provisioning">
        <t>AN is provisioned with a new pseudowire service instance. AN
        requests a required /32 FEC label from AGN1x using LDP DoD
        procedures.</t>

        <t>Following the initial setup phase described in section 3.1, the
        first service instance gets provisioned on AN. Let us assume this is a
        pseudowire (PW) that is associated with either an attachment circuit
        (AC for VPWS service) or a virtual switching instance (VSI for VPLS
        service). The type of PW service does not matter. This PW will be
        signaled using targeted LDP FEC128 (0x80). Hence the PW is provisioned
        with the PW ID and the loopback IP address of destination node.</t>

        <t>From IP/MPLS perspective, following label operations need to
        complete successfully to establish PW service:<list style="symbols">
            <t>LSP label for destination /32 FEC needs to be signaled using
            LDP DoD.</t>

            <t>PW label for specific PW ID FEC128 needs to be signaled using
            targeted LDP and PWE3 signaling procedure as per <xref
            target="RFC4447">RFC 4447</xref></t>
          </list></t>

        <t>AN has to establish a TCP/IP connection to the destination node for
        the targeted LDP session. This is done either by an explicit targeted
        LDP session configuration on AN (most likely) or automatically at the
        time of provisioning the PW.</t>

        <t>Destination node may be located in the local metro region or in a
        remote region. In the former case destination node is reachable via
        both native IP and MPLS LSPs, in the latter only via MPLS LSPs as
        transit core nodes do not hold remote AN IP routes. To ensure a common
        behavior for both cases, it is required that IP packets associated
        with this tLDP TCP/IP connection must be forwarded over an MPLS LSP to
        the destination, in other words LDP DoD label must be pushed on those
        packets by AN. This requires that LDP DoD is used for setting up MPLS
        LSP before tLDP session is established.</t>

        <t>To establish an LSP for destination /32 FEC, AN looks up its local
        routing table for this /32 and chooses outgoing interface. If label
        for this /32 route is not already installed based on the configured
        static route with LDP DoD request policy, AN MUST send an LDP DoD
        label mapping request over this interface to adjacent AGN1. AGN1
        replies with its label for this FEC. AGN1 MUST install this incoming
        label in its LIB and FIB. Upon receiving label mapping Access Node
        MUST accept this label based on the exact route match between
        advertised FEC and route entry in its RIB or based on the longest
        match based on <xref target="RFC5283"></xref>. If AN accepts the label
        it MUST install it as outgoing label in its LIB and FIB.</t>

        <t>If AN is dual homed to two AGN1&rsquo;s and routing entries for
        these AGN1&rsquo;s are configured as equal cost paths, Access Node
        MUST send LDP DoD label requests to both AGN1&rsquo;s and install all
        received labels in its LIB and FIB. If AN has multiple parallel links
        to AGN1 and routing entries for these links are configured as equal
        cost paths, same label should be used in LIB and programmed in the FIB
        for all these links.</t>

        <t>Following establishment of targeted LDP session, AN and the
        destination node exchange their PW label bindings based on the
        configured PW ID, and activate the PW service.</t>

        <t>In order to forward payload packets over the established PW, AN has
        to push PW encapsulation including the PW labels, followed by pushing
        the LSP label. AN chooses the LSP label based on the locally
        configured static route. If a specific route is reachable via multiple
        interfaces to AGN1 nodes (AN dual-homed, parallel links or both) and
        the route has multiple equal cost paths, Access Node MUST implement
        Equal Cost Multi-Path (ECMP) functionality. This involves AN to use
        hash-based load-balancing mechanism and send the PW packets in a
        flow-aware manner with appropriate LSP labels via all equal cost
        uplinks.</t>

        <t>ECMP mechanism is applicable in an equal manner for parallel links
        between two network elements and multiple paths towards the
        destination. The traffic demand is distributed over the available
        paths.</t>

        <t>To handle local link or adjacent node failures, AN should handle
        these local failures in a local-repair manner, that is AN should
        implement a simple LFA scheme. This will involve AN in case of primary
        interface failure choosing ECMP alternative or if not available a
        second best link.</t>
      </section>

      <section title="Access Node Service Decommissioning">
        <t>The last PW service instance is decommissioned. The LSP label is
        released.</t>

        <t>With the decommissioning of the service, the Pseudowire is deleted.
        If it is the last PW to the specific destination node, targeted LDP
        session is not longer needed and SHOULD be terminated (automated or by
        configuration).</t>

        <t>The LSP label is not longer required on AN for carrying any
        service.</t>

        <t>If the LSP label was originally requested based on the static route
        configuration with LDP DoD request policy, the label MUST be retained
        by AN.</t>

        <t>If /32 FEC label was originally requested based on tLDP session
        configuration, AN SHOULD delete the label from its LIB and FIB. The
        deletion of the label MAY be done immediately or with a Garbage
        Collection mechanism.</t>

        <t>If AN deletes the label, it MUST signal to AGN1 the Label Release
        Message, indicating the label is not longer required. This MAY be done
        immediately or with a Garbage Collection mechanism. The AGN1 MAY use
        this message to delete the label in its FIB, if it is not needed for
        other peers. However AGN1 MAY retain the label in its LIB.</t>
      </section>

      <section title="Service Failure">
        <t>A service instance has failed due to a network event. No impact on
        LDP DoD /32 FEC label.</t>

        <t>Variety of network events can trigger PW failure: <list
            style="symbols">
            <t>Local or remote attachment circuit has failed (remote end
            status signaled by targeted LDP).</t>

            <t>Local or remote PSN-facing PW (ingress or egress) has failed
            (remote end signaled by targeted LDP).</t>

            <t>PW is not in a enabled state for operation.</t>

            <t>PW OAM has signaled a failure (e.g. VCCV).</t>

            <t>Targeted LDP session is broken.</t>

            <t>Network link or node failures (described in <eref
            target="sec 3.5"></eref>).</t>
          </list>In all cases except the last one, the status of the PW
        service MUST not have any impact on the LSP label signaling. Therefore
        AN MUST NOT modify associated LSP label entries in its LIB and
        FIB.</t>
      </section>

      <section title="Network Transport Failure">
        <t>Number of different network events can impact services on AN.
        Following sections describe network event types that impact LDP DoD
        operation on AN and AGN1.</t>

        <section title="Access Node Failure">
          <t>Event: Access Node fails. Adjacent AGN1s delete LDP DoD /32 FEC
          labels for this AN.</t>

          <t>If AN fails, the link between AN and AGN1 goes down.</t>

          <t>AGN1 MUST remove associated static route(s) pointing to this AN
          from its routing table. AGN1 MUST also remove the associated
          outgoing label(s) for this AN&rsquo;s /32 loopback(s) from its FIB.
          AGN1 MAY remove the incoming labels provided to affected AN subject
          to other nodes using those labels or label retention procedures
          implemented on this AGN1.</t>

          <t>AGN1 SHOULD implement all relevant global-repair IP/MPLS
          procedures to propagate the AN failure towards the network.</t>
        </section>

        <section title="Access Node Uplink Failure">
          <t>Event: Link between AN and AGN1 fails. If last link, LDP DoD /32
          FEC labels get deleted on AN and AGN1s.</t>

          <t>In the event when AN-AGN1 link fails (and there are no more
          active L3 links connecting AN and AGN1) or the LDP DoD session
          between AN and AGN1 fails, both AN and AGN1 should take following
          actions.</t>

          <t><list style="symbols">
              <t>AN MUST delete /32 FEC label entries for labels provided by
              AGN1 affected by this link failure event, and remove those
              labels from its LIB and FIB tables.</t>

              <t>AGN1 MUST remove associated static route(s) pointing to this
              AN from its routing table.</t>

              <t>AGN1 MUST also remove the associated outgoing label(s) for
              this AN&rsquo;s /32 loopback(s) from its FIB.</t>

              <t>AGN1 MAY remove the incoming labels provided to affected AN
              subject to other nodes using those labels or label retention
              procedures implemented on this AGN1.</t>

              <t>In the event of interface or LDP DoD session coming back up,
              AN MUST request required labels observing procedures against
              link flapping.</t>

              <t>If AN is not redundantly connected to AGN1 nodes, in case of
              link failure, the service MUST go into a failure status on AN.
              When the failed link comes up again, the service MUST be
              reestablished automatically.</t>

              <t>If AN is connected to AGN1 over multiple parallel links
              implementing ECMP, in case of link failure, the service SHOULD
              be immediately re-routed to remaining links with the same /32
              FEC label.</t>

              <t>If AN is dual homed to two AGN1s (i.e. AGN11 and AGN12 in the
              reference topology), in case of link failure and isolation from
              one of the AGN1s, the service SHOULD be immediately re-routed by
              AN to use link(s) to the other AGN1.</t>
            </list></t>
        </section>

        <section title="AGN node failure">
          <t>AGN1 node fails. Adjacent ANs delete LDP DoD /32 FEC labels
          provided by this AGN1.</t>

          <t>If AGN1 fails, all links between this AGN1 and adjacent ANs go
          down.</t>

          <t>AN MUST remove from its RIB static route(s) pointing to this AGN1
          as a next hop. AN MUST also remove from its LIB and FIB all the
          outgoing labels provided by now failed AGN1. Access Node SHOULD use
          local-repair procedures to re-route away from the failure.</t>
        </section>

        <section title="AGN network-side reachability failure">
          <t>AGN1 loses network reachability to a specific destination or set
          of destinations. Associated /32 FEC labels are withdrawn from
          AN.</t>

          <t>In case of a network event that makes AGN1 lose its network
          reachability to a destination or set of destinations used by AN,
          AGN1 MUST send LDP Label Withdraw messages to all local ANs and
          withdraw labels for affected /32 FECs. Upon receiving those messages
          from AGN1, ANs MUST remove those labels from their LIB and FIB
          tables, and use alternative LSPs instead if available as part of
          global-repair.</t>
        </section>
      </section>
    </section>

    <section title="LDP Downstream on Demand Procedures">
      <t>Label Distribution Protocol is specified in <xref
      target="RFC5036">RFC5036</xref>, and all LDP DoD implementations must
      follow this specification.</t>

      <t>In MPLS network traffic flows from upstream to downstream LSR (<xref
      target="RFC3031">RFC3031</xref>, section 3.2). In case of downstream
      assigned labels as described in this document, labels are assigned by
      the downstream LSR and signaled to the upstream LSR as shown in figure
      below.</t>

      <t><figure>
          <artwork><![CDATA[              +----------+      +------------+
              | upstream |      | downstream |
        ------+   LSR    +------+    LSR     +----
    traffic   |          |      |            |  address 
    source    +----------+      +------------+  (/32 for IPv4)
                                                traffic
             label distribution for IPv4 FEC    destination
               <-------------------------      
                                               
                      traffic flow             
               ------------------------->
]]></artwork>

          <postamble>Figure 4. LDP label assignment direction</postamble>
        </figure></t>

      <section title="LDP Label Distribution Modes">
        <t>The LDP protocol specification <xref
        target="RFC5036">RFC5036</xref> section 2.6) defines two modes for
        label distribution control:<list style="symbols">
            <t>Independent &ndash; an LSR recognizes a particular FEC and
            makes the decision to bind a label to the FEC independently to
            distribute the bindings to its peers. The new FECs are recognized
            whenever new routes become visible to the router.</t>

            <t>Ordered &ndash; an LSR binds a label to a particular FEC if and
            only if it is the egress router or it has received a label binding
            for the FEC from its next hop LSR.</t>
          </list></t>

        <t>The LDP protocol specification (<xref
        target="RFC5036">RFC5036</xref> section 2.6) defines two modes for
        label retention: <list style="symbols">
            <t>Conservative &ndash; the bindings between a label and an FEC
            received from LSRs that are not the next hop for a given FEC are
            discarded. This mode requires an LSR to maintain fewer labels.</t>

            <t>Liberal &ndash; the bindings between a label and an FEC
            received from LSRs that are not the next hop for a given FEC are
            retained. This mode allows for quicker adaptation to topology
            changes and allows for the switching of traffic to other LSRs in
            case of change.</t>
          </list></t>

        <t>Note: In conservative label retention mode, if the next hop for FEC
        changes, then the LSR has to request a new label from the new next hop
        before labeled packets can be forwarded.</t>

        <t>For the LDP DoD Advertisement mode on AN an ordered label
        distribution mode and conservative label retention mode MUST be
        supported.</t>

        <t>With the ordered distribution mode, the AGN1 provides the access
        node only with FEC/label binding, where the AGN1 has a correct label
        binding itself.</t>

        <t>With the conservative retention mode, the AN retains only FEC/label
        binding on an interface, if the interface where the FEC/label mapping
        was received is a valid next hop. The DoD mode is explicitly mentioned
        in the description of the conservative mode in (<xref
        target="RFC5036">RFC5036</xref> section 2.6.2.1).</t>

        <t>The downstream labels on AGN1 may be allocated by LDP Downstream on
        Demand (LDP DoD) or LDP Downstream Unsolicited (LDP DU) or BGP labeled
        unicast routes that are learned as per <xref target="RFC3107">RFC
        3107</xref>. AGN1 should use the conservative label retention mode in
        case of Downstream on Demand label advertisement. AGN1 should use
        liberal retention mode in case of LDP DU label advertisement mode.
        AGN1 should establish either LDP DoD or LDP DU session to peer LSR
        based on LDP session negotiation procedure, specified in section 4.3.
        AGN1 must support interworking between LDP DoD and LDP DU sessions to
        different LSR peers.</t>

        <t></t>
      </section>

      <section title="IPv6 Support">
        <t>The current standard specifies the usage of IPv4 in LDP either as
        transport protocol or as service (binding of MPLS labels to Ipv4
        addresses). <xref target="RFC5036">RFC5036</xref> also describes the
        usage of IPv6 as transport protocol, but not as the service. For the
        future deployment, LDP DoD MUST also support IPv6 for transport and
        services. This is still under development (<xref
        target="I-D.ietf-mpls-ldp-ipv6"></xref>).</t>
      </section>

      <section title="LDP DoD Session Negotiation">
        <t>The AN should propose the Downstream on Demand label advertisement
        by setting "A" value as 1 in the Common Session Parameters TLV of the
        Initialization message. The rules for negotiating the label
        advertisement mode are specified in the section 3.5.3 of LDP protocol
        specification (<xref target="RFC5036">RFC5036</xref> .</t>

        <t>To establish Downstream on Demand session both AN and AGN1 should
        propose the Downstream on Demand label advertisement mode in the
        Initialization message for other than ATM/FR links. If AGN1 proposes
        Downstream Unsolicited mode, AN should send Notification with status
        "Session Rejected/Parameters Advertisement Mode&rdquo; and then close
        the LDP session.</t>

        <t>If AN is acting as active role, it should re-attempt the LDP
        session immediately. If AN receives same Downstream Unsolicited mode
        again, AN should follow the exponential backoff algorithm as specified
        in the (<xref target="RFC5036">RFC5036</xref> with delay of 15 seconds
        and subsequent delays grow to a maximum delay of 2 minutes.</t>

        <t>In case a PWE3 service is required between AN and AGN1, and LDP DoD
        has been negotiated for IPv4 and IPv6 FECs, the same LDP session
        should be used for PWE3 FECs. Even if DoD label advertisement has been
        negotiated for IPv4 and IPv6 LDP FECs as described earlier, LDP
        session should use Downstream Unsolicited label advertisement for PWE3
        FECs as specified in <xref target="RFC4447">RFC4447</xref>.</t>
      </section>

      <section title="Label Request Procedures">
        <t>The access node requests an MPLS label from the AGN1 with the Label
        Request Message (<xref target="RFC5036">RFC5036</xref> , section
        3.5.8). The FEC is the specific IP address of the requested Forwarding
        Equivalent Class (FEC). The MPLS Label is delivered with the Label
        Mapping Message (<xref target="RFC5036">RFC5036</xref> section
        3.5.7).</t>

        <section title="AN Label Request Procedure">
          <t>AN will request label bindings for AGN1 nodes as well as labels
          for the possible loopback addresses within seamless MPLS network
          based on following trigger events in addition to <xref
          target="RFC5036">RFC5036</xref>, section 3.5.8.1: <list
              style="symbols">
              <t>AN is configured with /32 static route with LDP DoD label
              request policy in line with AN start-up use case specified in
              section 3.1.</t>

              <t>AN is configured with service (e.g. PW) in line with PW
              provisioning use case described in section 2.2.</t>

              <t>AN and AGN1 link comes up and LDP DoD session is established.
              In this case AN should send label request messages for all /32
              static routes configured with LDP DoD policy and all /32 routes
              related to provisioned services (PW) that are not covered by
              static routes with LDP DoD policy.</t>
            </list></t>

          <t>AGN1 will respond with label mapping message with a non-null
          label if any of the below conditions are met on AGN1: <list
              style="symbols">
              <t>Requested FEC is a BGP labelled unicast route <xref
              target="RFC3107">RFC 3107</xref> and this BGP route is the best
              selected for this FEC or</t>

              <t>Requested FEC is an IGP or static route and there is an LDP
              label already learnt from downstream router (by LDP DU or LDP
              DoD), and this downstream router is the best next hop selected
              for this FEC. If selected downstream peer is LDP DoD and there
              is no label for this FEC, AGN1 will send a further label request
              message to this peer. In such case AGN1 will respond to AN only
              after getting a label from downstream peer.</t>
            </list></t>

          <t>AGN1 may send a label mapping with explicit-null or implicit-null
          label if it is acting as an egress for the requested FEC, or it may
          respond with &ldquo;No Route&ldquo; notification if no route
          exists.</t>
        </section>

        <section title="AGN Label Request Procedure">
          <t>AGN should send label request message based on the following
          trigger events in addition to <xref target="RFC5036">RFC5036</xref>,
          section 3.5.8.1: <list style="symbols">
              <t>AGN receives a label request from upstream LDP peer, has no
              downstream label for requested FEC and the downstream peer is
              LDP DoD, or</t>

              <t>AGN is configured with /32 static route with LDP DoD label
              request policy.</t>
            </list></t>

          <t>In case of ECMP, AGN should send label requests over all LDP DoD
          sessions associated with selected ECMP best next hops. In case of
          LFA, AGN should request labels over LDP DoD sessions associated with
          both primary and backup next hop routers.</t>

          <t>In both ECMP and LFA cases, downstream LSR may be AN. AN should
          respond back with label mapping to AGN if corresponding /32 route
          configuration (loopback address) exists, otherwise AN responds with
          &ldquo;No route&ldquo; notification.</t>
        </section>

        <section title="Label Request Retry Procedure">
          <t>If AN or AGN receives a &ldquo;No route&rdquo; Notification in
          response to its label request message, it should retry with
          exponential backoff algorithm similar to the backoff algoritm
          mentioned in the LDP session negotiation section 4.3.</t>

          <t>If there is no response to the sent label request message, the
          LDP specification <xref target="RFC5036">RFC 5036</xref> (section
          A.1.1, page# 100) states that LSR should not send another request
          for the same label to the peer and mandates that a duplicate label
          request is considered a protocol error and should be dropped by the
          receiving LSR by sending Notification message.</t>

          <t>AN or AGN1 should not send duplicate label request message again
          if there is no response from downstream peer.</t>

          <t>If the static route gets deleted or DoD request policy rejected
          for particular FEC before receiving label mapping message, then AN
          or AGN1 should send a Label Abort message to downstream router.</t>
        </section>
      </section>

      <section title="Label Withdraw Procedure">
        <t>If an MPLS label in the AGN1 is no longer valid, the AGN1 withdraws
        this FEC/label binding from the access nodes with the Label Withdraw
        Message ( <xref target="RFC5036">RFC 5036</xref> section 3.5.10) with
        a specified label TLV or with an empty label TLV.</t>

        <t>AGN1 should withdraw a label for specific FEC in the following
        cases: <list style="symbols">
            <t>If LDP DoD ingress label is associated with an outgoing label
            assigned by BGP labelled unicast route, this route is
            withdrawn.</t>

            <t>If LDP DoD ingress label is associated with an outgoing label
            assigned by LDP (DoD or DU) and IGP route is withdrawn from the
            RIB or downstream LDP session is lost.</t>

            <t>If LDP DoD ingress label is associated with an outgoing label
            assigned by LDP (DoD or DU) and received label is withdrawn by the
            downstream LSR.</t>

            <t>If LDP DoD ingress label is associated with an outgoing label
            assigned by LDP, route next hop changed and <list style="letters">
                <t>there is no LDP session to the new next hop. To minimize
                probability of this, AGN should implement LDP-IGP
                synchronization procedures as specified in <xref
                target="RFC5443">RFC 5443</xref>.</t>

                <t>there is an LDP session but no label from downstream LSR.
                See note below.</t>
              </list></t>

            <t>If AGN1 is configured with a policy to reject exporting label
            mappings to AN.</t>
          </list></t>

        <t>The access node responds with the Label Release Message (<xref
        target="RFC5036">RFC5036</xref> section 3.5.11).</t>

        <t>After sending label release message to AGN1, AN should keep retry
        sending label request message again, assuming AN still requires the
        label.</t>

        <t>AN should withdraw a label if the local route configuration (/32
        loopback) is deleted on the AN. But if a service (PW) is
        decommissioned, then AN will release the label &ndash; see cases
        described in the next section 4.6.</t>

        <t>Note: For any events inducing next hop change, AGN1 should attempt
        to converge the LSP locally before withdrawing the label from an
        upstream AN. For example if the next hop changes for a particular FEC
        and if the new next hop allocates labels by LDP DoD session, then AGN1
        must send label request on the new next hop session. If AGN1
        doesn&lsquo;t get label mapping for some duration, then and only then
        AGN1 must withdraw the upstream label.</t>
      </section>

      <section title="Label Release Procedure">
        <t>If an access node does not need any longer a label for an FEC, it
        sends a Label Release Message (<xref target="RFC5036">RFC 5036</xref>
        section 3.5.11) to the AGN1 with or without the label TLV.</t>

        <t>If AN or AGN1 receive unsolicited label mapping on DoD session,
        they should release the label by sending label release message.</t>

        <t>AN should send a label release message in the following cases:
        <list style="symbols">
            <t>If it receives a label withdraw from AGN.</t>

            <t>If /32 static route with LDP DoD label request policy is
            deleted.</t>

            <t>If service (PW) gets decommissioned and there is no
            corresponding /32 static route with LDP DoD label request policy
            configured.</t>

            <t>If the route next hop changed, and the label does not point to
            the best next hop.</t>
          </list></t>

        <t>AGN should send a label release message to downstream DoD session
        in the following cases:<list style="symbols">
            <t>If /32 static route with LDP DoD label request policy is
            deleted.</t>

            <t>If the route next hop changed, then AGN should send label
            release on the old next hop DoD session.</t>

            <t>If it receives label withdraw from downstream DoD session.</t>
          </list></t>
      </section>

      <section title="Local Repair">
        <t>To support local-repair with LFA, AGN1 should request labels from
        both primary (best) next hop and for backup (second best) next hop LDP
        DoD sessions as specified in the label request procedures in the
        section 4.4.2. This will enable AGN1 to pre-program the backup
        forwarding path with the backup label if the primary next hop link
        fails, and invoke LFA switch-over procedure.</t>

        <t>To support local repair on AN, AN should request label from the
        backup (second best) next hop. This will enable AN1 to pre-program the
        backup forwarding path with the backup label if the primary next hop
        link fails, and invoke LFA switch-over procedure.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Nischal Sheth, Nitin Bahadur and
      Nicolai Leymann for their suggestions and review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.4447'?>

      <?rfc include='reference.RFC.4446'?>

      <?rfc include='reference.RFC.5283'?>

      <?rfc include='reference.RFC.5036'?>

      <?rfc include='reference.RFC.3031'?>

      <?rfc include='reference.RFC.3107'?>

      <?rfc include='reference.RFC.5443'?>

      &I-D.mpls-seamless-mpls;

      &I-D.ietf-mpls-ldp-ipv6;
    </references>
  </back>
</rfc>

