| Network Working Group | T. Beckhaus |
| Internet-Draft | Deutsche Telekom AG |
| Intended status: Informational | B. Decraene |
| Expires: January 05, 2012 | France Telecom |
| K. Tiruveedhula | |
| M. Konstantynowicz | |
| Juniper Networks | |
| July 04, 2011 |
LDP Downstream-on-Demand in Seamless MPLS
draft-beckhaus-ldp-dod-00
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.
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].
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 05, 2012.
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.
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:
RFC 5036 [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).
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
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.
+----+ +-------+
| +------------------------+ +-------
|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:
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:
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 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].
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:
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 MUST also install the labels in its LIB and LFIB.
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:
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 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.
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 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.
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:
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.
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.
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.
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.
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.
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.
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 (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
The LDP protocol specification RFC5036 [RFC5036] section 2.6) defines two modes for label distribution control:
The LDP protocol specification (RFC5036 [RFC5036] section 2.6) defines two modes for label retention:
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.
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.
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]).
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 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].
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).
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:
AGN1 will respond with label mapping message with a non-null label if any of the below conditions are met on AGN1:
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.
AGN should send label request message based on the following trigger events in addition to RFC5036 [RFC5036], section 3.5.8.1:
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.
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.
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.
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:
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 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.
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:
AGN should send a label release message to downstream DoD session in the following cases:
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.
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.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
The authors would like to thank Nischal Sheth, Nitin Bahadur and Nicolai Leymann for their suggestions and review.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |