Network Working Group T. Beckhaus Internet-Draft Deutsche Telekom AG Intended status: Informational B. Decraene Expires: January 5, 2012 France Telecom K. Tiruveedhula M. Konstantynowicz Juniper Networks July 4, 2011 LDP Downstream-on-Demand in Seamless MPLS draft-beckhaus-ldp-dod-00 Abstract 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 RFC 5036 [RFC5036]. This document describes LDP DoD use cases and lists LDP DoD procedures in the context of Seamless MPLS design. Requirements Language 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 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 5, 2012. Beckhaus, et al. Expires January 5, 2012 [Page 1] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Reference Topologies . . . . . . . . . . . . . . . . . . . . . 4 3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Access Node Start-Up . . . . . . . . . . . . . . . . . . . 7 3.2. Access Node Service Provisioning . . . . . . . . . . . . . 8 3.3. Access Node Service Decommissioning . . . . . . . . . . . 9 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 10 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 11 3.5.1. Access Node Failure . . . . . . . . . . . . . . . . . 11 3.5.2. Access Node Uplink Failure . . . . . . . . . . . . . . 11 3.5.3. AGN node failure . . . . . . . . . . . . . . . . . . . 12 3.5.4. AGN network-side reachability failure . . . . . . . . 12 4. LDP Downstream on Demand Procedures . . . . . . . . . . . . . 12 4.1. LDP Label Distribution Modes . . . . . . . . . . . . . . . 13 4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 14 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 15 4.4.1. AN Label Request Procedure . . . . . . . . . . . . . . 15 4.4.2. AGN Label Request Procedure . . . . . . . . . . . . . 16 4.4.3. Label Request Retry Procedure . . . . . . . . . . . . 16 4.5. Label Withdraw Procedure . . . . . . . . . . . . . . . . . 17 4.6. Label Release Procedure . . . . . . . . . . . . . . . . . 18 4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Beckhaus, et al. Expires January 5, 2012 [Page 2] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 1. Introduction 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 RFC 5036 [RFC5036]. This document describes LDP DoD use cases and lists LDP DoD procedures in the context of Seamless MPLS design. 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. AN connectivity options include: o AN single-homed to an aggregation node (AGN) * with single link * with multiple parallel links (IP ECMP or L2 LAG) o AN dual-homed to two AGNs * with single link * with multiple parallel links (IP ECMP or L2 LAG) o AN daisy-chained via hub-AN * with single link * with multiple parallel links (IP ECMP or L2 LAG) 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's IP/MPLS devices despite the fact that it has been described in the original LDP specification RFC 5036 Beckhaus, et al. Expires January 5, 2012 [Page 3] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 [RFC5036]. This is because the original LDP DoD specification has been mainly used for ATM and FR-based MPLS LSRs in order to conserve available label space (i.e. with labels encoded in VPI/VCI). 2. Reference Topologies Following reference end to end network topology is used for review the LDP DoD use cases based on Seamless MPLS [I-D.ietf-mpls-seamless-mpls]: +-------+ +-------+ +------+ +------+ | | | | | | | | +--+ 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---------> Figure 1. End-to-end reference network topology. 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. Beckhaus, et al. Expires January 5, 2012 [Page 4] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 +----+ +-------+ | +------------------------+ +------- |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--> Figure 2. Dual-homed AN topology. A variant of AN topology is daisy-chained ANs shown in figure below: +-------+ | |---/ /----+ 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--> Figure 3. Daisy-chained AN topology. Access Node has at least following routing entries configured: Beckhaus, et al. Expires January 5, 2012 [Page 5] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 o Static default routes (0.0.0.0/0) pointing to all interfaces linking to AGN1 nodes, one per interface. o Specific static routes for /32 loopback address of the directly connected AGN1, pointing to all interfaces linked to this AGN1. If AN does not support RFC 5283 [RFC5283] 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. AGN1s have specific /32 static routes for adjacent AN'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. Note: Additional LDP features should be supported to comply with Seamless MPLS fast service restoration requirements as follows: o 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. o AGN1 should support local-repair in case of AN downlink failure, by implementing IGP LFA (w/ LDP support). o 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. o AN and AGN should be configured with LDP session protection to avoid delay upon the recovery from link failure. 3. LDP DoD Use Cases 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. Described LDP DoD operations apply equally to ANs connected over single links or parallel links (IP ECMP or L2 LAG). This document is focusing on IPv4 LDP DoD procedures. Similar Beckhaus, et al. Expires January 5, 2012 [Page 6] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 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 [I-D.ietf-mpls-ldp-ipv6]. 3.1. Access Node Start-Up 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. AN is only provisioned with the following static IP routing entries: o Static default route 0/0 pointing to interfaces connected to AGN1 (AGN11 and AGN12 if present). o Static route for adjacent AGN1's loopback, pointing to interfaces connected to AGN1. o (Optional) Static route for local metro AGN2's loopback, pointing to interfaces connected to AGN1. o (Optional) Static routes for other nodes within Seamless MPLS network. Note: last two entries are optional and not required if AN supports inter-area LDP RFC 5283 [RFC5283] and triggering of LDP DoD label mapping request by service (e.g. PW) configuration. IP/MPLS configuration on AN includes LDP sessions to loopback addresses of adjacent AGN1's. Source IP address for this LDP session is the loopback address of AN. 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. 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. AGN1 provides AN with requested labels and MUST install the labels in its label table (LIB) and its forwarding table (LFIB). Access Node Beckhaus, et al. Expires January 5, 2012 [Page 7] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 MUST also install the labels in its LIB and LFIB. 3.2. Access Node Service Provisioning AN is provisioned with a new pseudowire service instance. AN requests a required /32 FEC label from AGN1x using LDP DoD procedures. 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. From IP/MPLS perspective, following label operations need to complete successfully to establish PW service: o LSP label for destination /32 FEC needs to be signaled using LDP DoD. o PW label for specific PW ID FEC128 needs to be signaled using targeted LDP and PWE3 signaling procedure as per RFC 4447 [RFC4447] 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. 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. 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 Beckhaus, et al. Expires January 5, 2012 [Page 8] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 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 [RFC5283]. If AN accepts the label it MUST install it as outgoing label in its LIB and FIB. If AN is dual homed to two AGN1's and routing entries for these AGN1's are configured as equal cost paths, Access Node MUST send LDP DoD label requests to both AGN1'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. 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. 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. 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. 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. 3.3. Access Node Service Decommissioning The last PW service instance is decommissioned. The LSP label is released. 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 Beckhaus, et al. Expires January 5, 2012 [Page 9] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 by configuration). The LSP label is not longer required on AN for carrying any service. 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. 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. 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. 3.4. Service Failure A service instance has failed due to a network event. No impact on LDP DoD /32 FEC label. Variety of network events can trigger PW failure: o Local or remote attachment circuit has failed (remote end status signaled by targeted LDP). o Local or remote PSN-facing PW (ingress or egress) has failed (remote end signaled by targeted LDP). o PW is not in a enabled state for operation. o PW OAM has signaled a failure (e.g. VCCV). o Targeted LDP session is broken. o Network link or node failures (described in ). 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. Beckhaus, et al. Expires January 5, 2012 [Page 10] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 3.5. Network Transport Failure 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. 3.5.1. Access Node Failure Event: Access Node fails. Adjacent AGN1s delete LDP DoD /32 FEC labels for this AN. If AN fails, the link between AN and AGN1 goes down. 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'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. AGN1 SHOULD implement all relevant global-repair IP/MPLS procedures to propagate the AN failure towards the network. 3.5.2. Access Node Uplink Failure Event: Link between AN and AGN1 fails. If last link, LDP DoD /32 FEC labels get deleted on AN and AGN1s. 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. o 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. o AGN1 MUST remove associated static route(s) pointing to this AN from its routing table. o AGN1 MUST also remove the associated outgoing label(s) for this AN's /32 loopback(s) from its FIB. o 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. o In the event of interface or LDP DoD session coming back up, AN MUST request required labels observing procedures against link Beckhaus, et al. Expires January 5, 2012 [Page 11] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 flapping. o 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. o 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. o 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. 3.5.3. AGN node failure AGN1 node fails. Adjacent ANs delete LDP DoD /32 FEC labels provided by this AGN1. If AGN1 fails, all links between this AGN1 and adjacent ANs go down. 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. 3.5.4. AGN network-side reachability failure AGN1 loses network reachability to a specific destination or set of destinations. Associated /32 FEC labels are withdrawn from AN. 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. 4. LDP Downstream on Demand Procedures Label Distribution Protocol is specified in RFC5036 [RFC5036], and all LDP DoD implementations must follow this specification. In MPLS network traffic flows from upstream to downstream LSR Beckhaus, et al. Expires January 5, 2012 [Page 12] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 (RFC3031 [RFC3031], 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. +----------+ +------------+ | upstream | | downstream | ------+ LSR +------+ LSR +---- traffic | | | | address source +----------+ +------------+ (/32 for IPv4) traffic label distribution for IPv4 FEC destination <------------------------- traffic flow -------------------------> Figure 4. LDP label assignment direction 4.1. LDP Label Distribution Modes The LDP protocol specification RFC5036 [RFC5036] section 2.6) defines two modes for label distribution control: o Independent - 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. o Ordered - 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. The LDP protocol specification (RFC5036 [RFC5036] section 2.6) defines two modes for label retention: o Conservative - 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. o Liberal - 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. 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. Beckhaus, et al. Expires January 5, 2012 [Page 13] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 For the LDP DoD Advertisement mode on AN an ordered label distribution mode and conservative label retention mode MUST be supported. 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. 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 (RFC5036 [RFC5036] section 2.6.2.1). 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 RFC 3107 [RFC3107]. 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. 4.2. IPv6 Support The current standard specifies the usage of IPv4 in LDP either as transport protocol or as service (binding of MPLS labels to Ipv4 addresses). RFC5036 [RFC5036] 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 ([I-D.ietf-mpls-ldp-ipv6]). 4.3. LDP DoD Session Negotiation 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 (RFC5036 [RFC5036] . 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" and then close the Beckhaus, et al. Expires January 5, 2012 [Page 14] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 LDP session. 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 (RFC5036 [RFC5036] with delay of 15 seconds and subsequent delays grow to a maximum delay of 2 minutes. 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 RFC4447 [RFC4447]. 4.4. Label Request Procedures The access node requests an MPLS label from the AGN1 with the Label Request Message (RFC5036 [RFC5036] , 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 (RFC5036 [RFC5036] section 3.5.7). 4.4.1. AN Label Request Procedure 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 RFC5036 [RFC5036], section 3.5.8.1: o 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. o AN is configured with service (e.g. PW) in line with PW provisioning use case described in section 2.2. o 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. AGN1 will respond with label mapping message with a non-null label if any of the below conditions are met on AGN1: o Requested FEC is a BGP labelled unicast route RFC 3107 [RFC3107] and this BGP route is the best selected for this FEC or Beckhaus, et al. Expires January 5, 2012 [Page 15] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 o 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. 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 "No Route" notification if no route exists. 4.4.2. AGN Label Request Procedure AGN should send label request message based on the following trigger events in addition to RFC5036 [RFC5036], section 3.5.8.1: o AGN receives a label request from upstream LDP peer, has no downstream label for requested FEC and the downstream peer is LDP DoD, or o AGN is configured with /32 static route with LDP DoD label request policy. 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. 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 "No route" notification. 4.4.3. Label Request Retry Procedure If AN or AGN receives a "No route" 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. If there is no response to the sent label request message, the LDP specification RFC 5036 [RFC5036] (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. Beckhaus, et al. Expires January 5, 2012 [Page 16] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 AN or AGN1 should not send duplicate label request message again if there is no response from downstream peer. 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. 4.5. Label Withdraw Procedure 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 ( RFC 5036 [RFC5036] section 3.5.10) with a specified label TLV or with an empty label TLV. AGN1 should withdraw a label for specific FEC in the following cases: o If LDP DoD ingress label is associated with an outgoing label assigned by BGP labelled unicast route, this route is withdrawn. o 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. o 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. o If LDP DoD ingress label is associated with an outgoing label assigned by LDP, route next hop changed and A. 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 RFC 5443 [RFC5443]. B. there is an LDP session but no label from downstream LSR. See note below. o If AGN1 is configured with a policy to reject exporting label mappings to AN. The access node responds with the Label Release Message (RFC5036 [RFC5036] section 3.5.11). After sending label release message to AGN1, AN should keep retry sending label request message again, assuming AN still requires the label. AN should withdraw a label if the local route configuration (/32 Beckhaus, et al. Expires January 5, 2012 [Page 17] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 loopback) is deleted on the AN. But if a service (PW) is decommissioned, then AN will release the label - see cases described in the next section 4.6. 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't get label mapping for some duration, then and only then AGN1 must withdraw the upstream label. 4.6. Label Release Procedure If an access node does not need any longer a label for an FEC, it sends a Label Release Message (RFC 5036 [RFC5036] section 3.5.11) to the AGN1 with or without the label TLV. If AN or AGN1 receive unsolicited label mapping on DoD session, they should release the label by sending label release message. AN should send a label release message in the following cases: o If it receives a label withdraw from AGN. o If /32 static route with LDP DoD label request policy is deleted. o If service (PW) gets decommissioned and there is no corresponding /32 static route with LDP DoD label request policy configured. o If the route next hop changed, and the label does not point to the best next hop. AGN should send a label release message to downstream DoD session in the following cases: o If /32 static route with LDP DoD label request policy is deleted. o If the route next hop changed, then AGN should send label release on the old next hop DoD session. o If it receives label withdraw from downstream DoD session. 4.7. Local Repair 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 Beckhaus, et al. Expires January 5, 2012 [Page 18] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 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. 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. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations 7. Acknowledgements The authors would like to thank Nischal Sheth, Nitin Bahadur and Nicolai Leymann for their suggestions and review. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.ietf-mpls-ldp-ipv6] Manral, V., Papneja, R., Asati, R., and C. Pignataro, "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-04 (work in progress), May 2011. [I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", draft-ietf-mpls-seamless-mpls-00 (work in progress), May 2011. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Beckhaus, et al. Expires January 5, 2012 [Page 19] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 Label Switching Architecture", RFC 3031, January 2001. [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008. [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009. Authors' Addresses Thomas Beckhaus Deutsche Telekom AG Heinrich-Hertz-Strasse 3-7 Darmstadt, 64307 Germany Phone: +49 6151 58 12825 Fax: Email: thomas.beckhaus@telekom.de URI: Bruno Decraene France Telecom 38-40 rue du General Leclerc Issy Moulineaux cedex 9, 92794 France Phone: Fax: Email: bruno.decraene@orange-ftgroup.com URI: Beckhaus, et al. Expires January 5, 2012 [Page 20] Internet-Draft LDP Downstream-on-Demand in Seamless MPLS July 2011 Kishore Tiruveedhula Juniper Networks 10 Technology Park Drive Westford, Massachusetts 01886 USA Phone: 1-(978)-589-8861 Fax: Email: kishoret@juniper.net URI: Maciek Konstantynowicz Juniper Networks Phone: Fax: Email: maciek@juniper.net URI: Beckhaus, et al. Expires January 5, 2012 [Page 21]