draft-ietf-mpls-ldp-dod-09.txt   rfc7032.txt 
Network Working Group T. Beckhaus, Ed. Internet Engineering Task Force (IETF) T. Beckhaus, Ed.
Internet-Draft Deutsche Telekom AG Request for Comments: 7032 Deutsche Telekom AG
Intended status: Standards Track B. Decraene Category: Standards Track B. Decraene
Expires: January 14, 2014 Orange ISSN: 2070-1721 Orange
K. Tiruveedhula K. Tiruveedhula
Juniper Networks Juniper Networks
M. Konstantynowicz, Ed. M. Konstantynowicz, Ed.
L. Martini L. Martini
Cisco Systems, Inc. Cisco Systems, Inc.
July 13, 2013 October 2013
LDP Downstream-on-Demand in Seamless MPLS LDP Downstream-on-Demand in Seamless MPLS
draft-ietf-mpls-ldp-dod-09
Abstract Abstract
Seamless MPLS design enables a single IP/MPLS network to scale over Seamless MPLS design enables a single IP/MPLS network to scale over
core, metro and access parts of a large packet network infrastructure core, metro, and access parts of a large packet network
using standardized IP/MPLS protocols. One of the key goals of infrastructure using standardized IP/MPLS protocols. One of the key
Seamless MPLS is to meet requirements specific to access, including goals of Seamless MPLS is to meet requirements specific to access
high number of devices, their position in network topology and their networks including high number of devices, device position in network
compute and memory constraints that limit the amount of state access topology, and compute and memory constraints that limit the amount of
devices can hold.This can be achieved with LDP Downstream-on-Demand state access devices can hold. This can be achieved with LDP
(LDP DoD) label advertisement. This document describes LDP DoD use Downstream-on-Demand (DoD) label advertisement. This document
cases and lists required LDP DoD procedures in the context of describes LDP DoD use cases and lists required LDP DoD procedures in
Seamless MPLS design. the context of Seamless MPLS design.
In addition, a new optional TLV type in the LDP Label Request message In addition, a new optional TLV type in the LDP Label Request message
is defined for fast-up convergence. is defined for fast-up convergence.
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 RFC2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on January 14, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7032.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................4
2. Reference Topologies . . . . . . . . . . . . . . . . . . . . 4 2. Reference Topologies ............................................6
2.1. Access Topologies with Static Routing . . . . . . . . . . 5 2.1. Access Topologies with Static Routing ......................6
2.2. Access Topologies with Access IGP . . . . . . . . . . . . 7 2.2. Access Topologies with Access IGP .........................10
3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 3. LDP DoD Use Cases ..............................................11
3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 9 3.1. Initial Network Setup .....................................12
3.1.1. AN with Static Routing . . . . . . . . . . . . . . . 9 3.1.1. AN with Static Routing .............................12
3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . 11 3.1.2. AN with Access IGP .................................13
3.2. Service Provisioning and Activation . . . . . . . . . . . 11 3.2. Service Provisioning and Activation .......................14
3.3. Service Changes and Decommissioning . . . . . . . . . . . 14 3.3. Service Changes and Decommissioning .......................16
3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 14 3.4. Service Failure ...........................................17
3.5. Network Transport Failure . . . . . . . . . . . . . . . . 15 3.5. Network Transport Failure .................................17
3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 15 3.5.1. General Notes ......................................17
3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 15 3.5.2. AN Failure .........................................18
3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 16 3.5.3. AN/AGN Link Failure ................................19
3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . 17 3.5.4. AGN Failure ........................................20
3.5.5. AGN Network-side Reachability Failure . . . . . . . . 18 3.5.5. AGN Network-Side Reachability Failure ..............20
4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . 18 4. LDP DoD Procedures .............................................20
4.1. LDP Label Distribution Control and Retention Modes . . . 19 4.1. LDP Label Distribution Control and Retention Modes ........21
4.2. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 20 4.2. LDP DoD Session Negotiation ...............................23
4.3. Label Request Procedures . . . . . . . . . . . . . . . . 21 4.3. Label Request Procedures ..................................23
4.3.1. Access LSR/ABR Label Request . . . . . . . . . . . . 21 4.3.1. Access LSR/ABR Label Request .......................23
4.3.2. Label Request Retry . . . . . . . . . . . . . . . . . 22 4.3.2. Label Request Retry ................................24
4.4. Label Withdraw . . . . . . . . . . . . . . . . . . . . . 23 4.4. Label Withdraw ............................................25
4.5. Label Release . . . . . . . . . . . . . . . . . . . . . . 24 4.5. Label Release .............................................26
4.6. Local Repair . . . . . . . . . . . . . . . . . . . . . . 24 4.6. Local-Repair ..............................................27
5. LDP Extension for LDP DoD Fast-Up Convergence . . . . . . . . 24 5. LDP Extension for LDP DoD Fast-Up Convergence ..................27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations ............................................29
6.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . 26 6.1. LDP TLV Type ..............................................29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations ........................................29
7.1. LDP DoD Native Security Properties . . . . . . . . . . . 27 7.1. LDP DoD Native Security Properties ........................30
7.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 28 7.2. Data-Plane Security .......................................31
7.3. Control Plane Security . . . . . . . . . . . . . . . . . 29 7.3. Control-Plane Security ....................................31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgements ...............................................32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References .....................................................33
9.1. Normative References . . . . . . . . . . . . . . . . . . 30 9.1. Normative References ......................................33
9.2. Informative References . . . . . . . . . . . . . . . . . 30 9.2. Informative References ....................................33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single Seamless MPLS design [SEAMLESS-MPLS] enables a single IP/MPLS network
IP/MPLS network to scale over core, metro and access parts of a large to scale over core, metro, and access parts of a large packet network
packet network infrastructure using standardized IP/MPLS protocols. infrastructure using standardized IP/MPLS protocols. One of the key
One of the key goals of Seamless MPLS is to meet requirements goals of Seamless MPLS is to meet requirements specific to access
specific to access, including high number of devices, their position including high number of devices, device position in network
in network topology and their compute and memory constraints that topology, and compute and memory constraints that limit the amount of
limit the amount of state access devices can hold. state access devices can hold.
In general MPLS Label Switching Routers implement either LDP or RSVP In general, MPLS Label Switching Routers (LSRs) implement either LDP
for MPLS label distribution. or RSVP for MPLS label distribution.
The focus of this document is on LDP, as Seamless MPLS design does The focus of this document is on LDP, as Seamless MPLS design does
not include a requirement for general purpose explicit traffic not include a requirement for general-purpose explicit traffic
engineering and bandwidth reservation. Document concentrates on the engineering and bandwidth reservation. This document concentrates on
unicast connectivity only. Multicast connectivity is subject for the unicast connectivity only. Multicast connectivity is a subject
further study. for further study.
In Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], IP/MPLS In Seamless MPLS design [SEAMLESS-MPLS], IP/MPLS protocol
protocol optimization is possible due to a relatively simple access optimization is possible due to relatively simple access network
network topologies. Examples of such topologies involving access topologies. Examples of such topologies involving access nodes (ANs)
nodes (AN) and aggregation nodes (AGN) include: and aggregation nodes (AGNs) include:
a. A single AN homed to a single AGN. a. A single AN homed to a single AGN.
b. A single AN dual-homed to two AGNs. b. A single AN dual-homed to two AGNs.
c. Multiple ANs daisy-chained via a hub-AN to a single AGN. c. Multiple ANs daisy-chained via a hub-AN to a single AGN.
d. Multiple ANs daisy-chained via a hub-AN to two AGNs. d. Multiple ANs daisy-chained via a hub-AN to two AGNs.
e. Two ANs dual-homed to two AGNs. e. Two ANs dual-homed to two AGNs.
f. Multiple ANs chained in a ring and dual-homed to two AGNs. f. Multiple ANs chained in a ring and dual-homed to two AGNs.
The amount of IP RIB and FIB state on ANs can be easily controlled in The amount of IP Routing Information Base (RIB) and Forwarding
the listed access topologies by using simple IP routing configuration Information Base (FIB) state on ANs can be easily controlled in the
listed access topologies by using simple IP routing configuration
with either static routes or dedicated access IGP. Note that in all with either static routes or dedicated access IGP. Note that in all
of the above topologies AGNs act as the access border routers (access of the above topologies, AGNs act as the access area border routers
ABRs) connecting the access topology to the rest of the network. (access ABRs) connecting the access topology to the rest of the
Hence in many cases it is sufficient for ANs to have a default route network. Hence, in many cases, it is sufficient for ANs to have a
pointing towards AGNs in order to achieve complete network default route pointing towards AGNs in order to achieve complete
connectivity from ANs to the network. network connectivity from ANs to the network.
The amount of MPLS forwarding state however requires additional However, the amount of MPLS forwarding state requires additional
consideration. In general MPLS routers implement LDP Downstream consideration. In general, MPLS routers implement LDP Downstream
Unsolicited (LDP DU) label advertisement [RFC5036] and advertise MPLS Unsolicited (LDP DU) label advertisements [RFC5036] and advertise
labels for all valid routes in their RIB. This is seen as an MPLS labels for all valid routes in their RIB tables. This is seen
inadequate approach for ANs, which requires a small subset of the as an inadequate approach for ANs, which require a small subset of
total routes (and associated labels) based on the required the total routes (and associated labels) based on the required
connectivity for the provisioned services. And although filters can connectivity for the provisioned services. Although filters can be
be applied to those LDP DU labels advertisements, it is not seen as a applied to those LDP DU label advertisements, it is not seen as a
suitable tool to facilitate any-to-any AN-driven connectivity between suitable tool to facilitate any-to-any AN-driven connectivity between
access and the rest of the MPLS network. access and the rest of the MPLS network.
This document describes an access node driven "subscription model" This document describes an AN-driven "subscription model" for label
for label distribution in the access. The approach relies on the distribution in the access network. The approach relies on the
standard LDP Downstream-on-Demand (LDP DoD) label advertisements as standard LDP DoD label advertisements as specified in [RFC5036]. LDP
specified in [RFC5036]. LDP DoD enables on-demand label distribution DoD enables on-demand label distribution ensuring that only required
ensuring that only required labels are requested, provided and labels are requested, provided, and installed. Procedures described
installed. Procedures described in this document are equally in this document are equally applicable to LDP IPv4 and IPv6 address
applicable to LDP IPv4 and IPv6 address families. For simplicity the families. For simplicity, the document provides examples based on
document provides examples based on LDP IPv4 address family. the LDP IPv4 address family.
The following sections describe a set of reference access topologies The following sections describe a set of reference access topologies
considered for LDP DoD usage and their associated IP routing considered for LDP DoD usage and their associated IP routing
configurations, followed by LDP DoD use cases and LDP DoD procedures configurations, followed by LDP DoD use cases and LDP DoD procedures
in the context of Seamless MPLS design. 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 [RFC2119].
2. Reference Topologies 2. Reference Topologies
LDP DoD use cases are described in the context of a generic reference LDP DoD use cases are described in the context of a generic reference
end-to-end network topology based on Seamless MPLS design end-to-end network topology based on Seamless MPLS design
[I-D.ietf-mpls-seamless-mpls] shown in Figure 1 [SEAMLESS-MPLS] as shown in Figure 1.
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
---+ AGN11 +--+ AGN21 +--+ ABR1 +--+ LSR1 +--> to LSR/AGN ---+ AGN11 +--+ AGN21 +--+ ABR1 +--+ LSR1 +--> to LSR/AGN
+--------+/ +-------+ +-------+ +------+ +------+ +--------+/ +-------+ +-------+ +------+ +------+
| Access | \/ \/ | Access | \/ \/
| Network| /\ /\ | Network| /\ /\
+--------+ +-------+ +-------+ +------+ +------+ +--------+ +-------+ +-------+ +------+ +------+
\---+ AGN12 +--+ AGN22 +--+ ABR2 +--+ LSR2 +--> to LSR/AGN \---+ AGN12 +--+ AGN22 +--+ ABR2 +--+ LSR2 +--> to LSR/AGN
+-------+ +-------+ +------+ +------+ +-------+ +-------+ +------+ +------+
static routes static routes
or access IGP IGP area IGP area or access IGP IGP area IGP area
<----Access----><--Aggregation Domain--><----Core-----> <----Access----><--Aggregation Domain--><----Core----->
<------------------------- MPLS ----------------------> <------------------------- MPLS ---------------------->
Figure 1: Seamless MPLS end-to-end reference network topology. Figure 1: Seamless MPLS End-to-End Reference Network Topology
The access network is either single or dual homed to AGN1x, with The access network is either single- or dual-homed to AGN1x, with
either a single or multiple parallel links to AGN1x. either a single parallel link or multiple parallel links to AGN1x.
Seamless MPLS access network topologies can range from a single- or Seamless MPLS access network topologies can range from a single- or
dual-homed access node to a chain or ring of access nodes, and use dual-homed access node to a chain or ring of access nodes, and it can
either static routing or access IGP ( ISIS or OSPF ). The following use either static routing or access IGP (IS-IS or OSPF). The
sections describe reference access topologies in more detail. following sections describe reference access topologies in more
detail.
2.1. Access Topologies with Static Routing 2.1. Access Topologies with Static Routing
In most cases access nodes connect to the rest of the network using In most cases, access nodes connect to the rest of the network using
very simple topologies. Here static routing is sufficient to provide very simple topologies. Here, static routing is sufficient to
the required IP connectivity. The following topologies are provide the required IP connectivity. The following topologies are
considered for use with static routing and LDP DoD: considered for use with static routing and LDP DoD:
a. [I1] topology - a single AN homed to a single AGN. a. [I1] topology - a single AN homed to a single AGN.
b. [I] topology - multiple ANs daisy-chained to a single AGN. b. [I] topology - multiple ANs daisy-chained to a single AGN.
c. [V] topology - a single AN dual-homed to two AGNs. c. [V] topology - a single AN dual-homed to two AGNs.
d. [U2] topology - two ANs dual-homed to two AGNs. d. [U2] topology - two ANs dual-homed to two AGNs.
e. [Y] topology - multiple ANs daisy-chained to two AGNs. e. [Y] topology - multiple ANs daisy-chained to two AGNs.
The reference static routing and LDP configuration for [V] access The reference static routing and LDP configuration for [V] access
topology is shown in Figure 2. The same static routing and LDP topology is shown in Figure 2. The same static routing and LDP
configuration also applies to [I1] topology. configuration also applies to the [I1] topology.
+----+ +-------+ +----+ +-------+
|AN1 +------------------------+ AGN11 +------- |AN1 +------------------------+ AGN11 +-------
| +-------\ /-----------+ +-\ / | +-------\ /-----------+ +-\ /
+----+ \ / +-------+ \ / +----+ \ / +-------+ \ /
\/ \/ \/ \/
/\ /\ /\ /\
+----+ / \ +-------+ / \ +----+ / \ +-------+ / \
|AN2 +-------/ \-----------+ AGN12 +-/ \ |AN2 +-------/ \-----------+ AGN12 +-/ \
| +------------------------+ +------- | +------------------------+ +-------
+----+ +-------+ +----+ +-------+
--(u)-> <-(d)-- --(u)-> <-(d)--
<----- static routing -------> <--- IGP ----> <----- static routing -------> <------ IGP ------>
<-- LDP DU --> <---- LDP DU ----->
<--------- LDP DoD ----------> <-- BGP LU --> <--------- LDP DoD ----------> <-- labeled BGP -->
(u) static routes: 0/0 default, (optional) /32 routes (u) static routes: 0/0 default, (optional) /32 routes
(d) static routes: AN loopbacks (d) static routes: AN loopbacks
Figure 2: [V] access topology with static routes. Figure 2: [V] Access Topology with Static Routes
In line with the Seamless MPLS design, static routes configured on In line with the Seamless MPLS design, static routes configured on
AGN1x and pointing towards the access network are redistributed in AGN1x and pointing towards the access network are redistributed in
either IGP or BGP labeled unicast (BGP-LU) [RFC3107]. either IGP or BGP labeled IP routes [RFC3107].
The reference static routing and LDP configuration for [U2] access The reference static routing and LDP configuration for [U2] access
topology is shown in Figure 3. topology is shown in Figure 3.
+----+ +-------+ +----+ +-------+
(d1) |AN1 +------------------------+ AGN11 +------- (d1) |AN1 +------------------------+ AGN11 +-------
| | + + +-\ / | | + + +-\ /
v +-+--+ +-------+ \ / v +-+--+ +-------+ \ /
| \/ | \/
| /\ | /\
^ +-+--+ +-------+ / \ ^ +-+--+ +-------+ / \
| |AN2 + + AGN12 +-/ \ | |AN2 + + AGN12 +-/ \
(d2) | +------------------------+ +------- (d2) | +------------------------+ +-------
+----+ +-------+ +----+ +-------+
--(u)-> <-(d)-- --(u)-> <-(d)--
<------- static routing --------> <--- IGP ----> <----- static routing -------> <------ IGP ------>
<-- LDP DU --> <---- LDP DU ----->
<----------- LDP DoD -----------> <-- BGP LU --> <--------- LDP DoD ----------> <-- labeled BGP -->
(u) static route 0/0 default, (optional) /32 routes (u) static route 0/0 default, (optional) /32 routes
(d) static route for AN loopbacks (d) static route for AN loopbacks
(d1) static route for AN2 loopback and 0/0 default with (d1) static route for AN2 loopback and 0/0 default with
lower preference lower preference
(d2) static route for AN1 loopback and 0/0 default with (d2) static route for AN1 loopback and 0/0 default with
lower preference lower preference
Figure 3: [U2] access topology with static routes. Figure 3: [U2] Access Topology with Static Routes
The reference static routing and LDP configuration for [Y] access The reference static routing and LDP configuration for [Y] access
topology is shown in Figure 4. The same static routing and LDP topology is shown in Figure 4. The same static routing and LDP
configuration also applies to [I] topology. configuration also applies to the [I] topology.
+-------+ +-------+
| |---/ | |---/
/----+ AGN11 | /----+ AGN11 |
+----+ +----+ +----+ / | |---\ +----+ +----+ +----+ / | |---\
| | | | | +----/ +-------+ | | | | | +----/ +-------+
|ANn +...|AN2 +---+AN1 | |ANn +...|AN2 +---+AN1 |
| | | | | +----\ +-------+ | | | | | +----\ +-------+
+----+ +----+ +----+ \ | |---/ +----+ +----+ +----+ \ | |---/
\----+ AGN12 | \----+ AGN12 |
<-(d2)-- <-(d1)-- | |---\ <-(d2)-- <-(d1)-- | |---\
--(u)-> --(u)-> --(u)-> +-------+ --(u)-> --(u)-> --(u)-> +-------+
<-(d)-- <-(d)--
<------- static routing -------> <--- IGP ----> <------- static routing --------> <------ IGP ------>
<-- LDP DU --> <---- LDP DU ----->
<---------- LDP DoD -----------> <-- BGP LU --> <----------- LDP DoD -----------> <-- labeled BGP -->
(u) static routes: 0/0 default, (optional) /32 routes (u) static routes: 0/0 default, (optional) /32 routes
(d) static routes: AN loopbacks [1..n] (d) static routes: AN loopbacks [1..n]
(d1) static routes: AN loopbacks [2..n] (d1) static routes: AN loopbacks [2..n]
(d2) static routes: AN loopbacks [3..n] (d2) static routes: AN loopbacks [3..n]
Figure 4: [Y] access topology with static routes. Figure 4: [Y] Access Topology with Static Routes
Note that in all of the above topologies parallel ECMP (or L2 LAG) Note that in all of the above topologies, parallel Equal-Cost
links can be used between the nodes. Multipath (ECMP) (or Layer 2 Link Aggregation Group (L2 LAG)) links
can be used between the nodes.
ANs support Inter-area LDP [RFC5283] in order to use the IP default ANs support Inter-area LDP [RFC5283] in order to use the IP default
route to match the LDP FEC advertised by AGN1x and other ANs. route to match the LDP Forwarding Equivalence Class (FEC) advertised
by AGN1x and other ANs.
2.2. Access Topologies with Access IGP 2.2. Access Topologies with Access IGP
A dedicated access IGP instance is used in the access network to A dedicated access IGP instance is used in the access network to
perform the internal routing between AGN1x and connected AN devices. perform the internal routing between AGN1x and connected AN devices.
Example of such IGP could be ISIS, OSPFv2&v3, RIPv2&RIPng. This Examples of such an IGP could be IS-IS, OSPFv2 and v3, or RIPv2 and
access IGP instance is distinct from the IGP of the aggegation RIPng. This access IGP instance is distinct from the IGP of the
domain. aggregation domain.
The following topologies are considered for use with access IGP The following topologies are considered for use with access IGP
routing and LDP DoD: routing and LDP DoD:
a. [U] topology - multiple ANs chained in an open ring and dual- a. [U] topology - multiple ANs chained in an open ring and dual-
homed to two AGNs. homed to two AGNs.
b. [Y] topology - multiple ANs daisy-chained via a hub-AN to two b. [Y] topology - multiple ANs daisy-chained via a hub-AN to two
AGNs. AGNs.
The reference access IGP and LDP configuration for [U] access The reference access IGP and LDP configuration for [U] access
topology is shown in Figure 5. topology is shown in Figure 5.
+-------+
+-----+ +-----+ +----+ | +---/
| AN3 |---| AN2 |---|AN1 +-----+ AGN11 |
+-----+ +-----+ +----+ | +---\
. +-------+
.
. +-------+
+-----+ +-----+ +----+ | +---/
|ANn-2|---|ANn-1|---|ANn +-----+ AGN12 |
+-----+ +-----+ +----+ | +---\
+-------+
+-------+ <---------- access IGP ------------> <------ IGP ------>
+-----+ +-----+ +----+ | +---/ <---- LDP DU ----->
| AN3 |---| AN2 |---|AN1 +-----+ AGN11 | <------------ LDP DoD -------------> <-- labeled BGP -->
+-----+ +-----+ +----+ | +---\
. +-------+
.
. +-------+
+-----+ +-----+ +----+ | +---/
|ANn-2|---|ANn-1|---|ANn +-----+ AGN12 |
+-----+ +-----+ +----+ | +---\
+-------+
<---------- access IGP ------------> <--- IGP ---->
<-- LDP DU -->
<------------ LDP DoD -------------> <-- BGP LU -->
Figure 5: [U] access topology with access IGP. Figure 5: [U] Access Topology with Access IGP
The reference access IGP and LDP configuration for [Y] access The reference access IGP and LDP configuration for [Y] access
topology is shown in Figure 6. topology is shown in Figure 6.
+-------+
| |---/
/----+ AGN11 |2
+----+ +----+ +----+ / | |---\
| | | | | +----/ +-------+
|ANn +...|AN2 +---+AN1 |
| | | | | +----\ +-------+
+----+ +----+ +----+ \ | |---/
\----+ AGN12 |
| |---\
+-------+
+-------+ <---------- access IGP ------------> <------ IGP ------>
| |---/ <---- LDP DU ----->
/----+ AGN11 |2 <------------ LDP DoD -------------> <-- labeled BGP -->
+----+ +----+ +----+ / | |---\
| | | | | +----/ +-------+
|ANn +...|AN2 +---+AN1 |
| | | | | +----\ +-------+
+----+ +----+ +----+ \ | |---/
\----+ AGN12 |
| |---\
+-------+
<---------- access IGP ------------> <--- IGP ---->
<-- LDP DU -->
<------------ LDP DoD -------------> <-- BGP LU -->
Figure 6: [Y] access topology with access IGP. Figure 6: [Y] Access Topology with Access IGP
Note that in all of the above topologies parallel ECMP (or L2 LAG) Note that in all of the above topologies, parallel ECMP (or L2 LAG)
links can be used between the nodes. links can be used between the nodes.
In both of the above topologies, ANs (ANn ... AN1) and AGN1x share In both of the above topologies, ANs (ANn ... AN1) and AGN1x share
the access IGP and advertise their IPv4 and IPv6 loopbacks and link the access IGP and advertise their IPv4 and IPv6 loopbacks and link
addresses. AGN1x advertise a default route into the access IGP. addresses. AGN1x advertises a default route into the access IGP.
ANs support Inter-area LDP [RFC5283] in order to use the IP default ANs support Inter-area LDP [RFC5283] in order to use the IP default
route for matching the LDP FECs advertised by AGN1x or other ANs. route for matching the LDP FECs advertised by AGN1x or other ANs.
3. LDP DoD Use Cases 3. LDP DoD Use Cases
LDP DoD use cases described in this document are based on the LDP DoD use cases described in this document are based on the
Seamless MPLS scenarios listed in Seamless MPLS design Seamless MPLS scenarios listed in Seamless MPLS design
[I-D.ietf-mpls-seamless-mpls]. This section illustrates these use [SEAMLESS-MPLS]. This section illustrates these use cases focusing
cases focusing on services provisioned on the access nodes and on services provisioned on the access nodes and clarifies expected
clarifies expected LDP DoD operation on the AN and AGN1x devices. LDP DoD operation on the AN and AGN1x devices. Two representative
Two representative service types are used to illustrate the service service types are used to illustrate the service use cases: MPLS
use cases: MPLS PWE3 [RFC4447] and BGP/MPLS IPVPN [RFC4364]. Pseudowire Edge-to-Edge (PWE3) [RFC4447] and BGP/MPLS IP VPN
[RFC4364].
Described LDP DoD operations apply equally to all reference access Described LDP DoD operations apply equally to all reference access
topologies described in Section 2. Operations that are specific to topologies described in Section 2. Operations that are specific to
certain access topologies are called out explicitly. certain access topologies are called out explicitly.
References to upstream and downstream nodes are made in line with the References to upstream and downstream nodes are made in line with the
definition of upstream and downstream LSR [RFC3031]. definition of upstream and downstream LSRs [RFC3031].
LDP DoD procedures follow the LDP specification [RFC5036], and are
equally applicable to LDP IPv4 and IPv6 address families. For
simplicity examples are provided for LDP IPv4 address family only.
3.1. Initial Network Setup 3.1. Initial Network Setup
An access node is commissioned without any services provisioned on An access node is commissioned without any services provisioned on
it. The AN can request labels for loopback addresses of any AN, AGN it. The AN can request labels for loopback addresses of any AN, AGN,
or other nodes within Seamless MPLS network for operational and or other nodes within the Seamless MPLS network for operational and
management purposes. It is assumed that AGN1x has required IP/MPLS management purposes. It is assumed that AGN1x has the required
configuration for network-side connectivity in line with Seamless IP/MPLS configuration for network-side connectivity in line with
MPLS design [I-D.ietf-mpls-seamless-mpls]. Seamless MPLS design [SEAMLESS-MPLS].
LDP sessions are configured between adjacent ANs and AGN1x using LDP sessions are configured between adjacent ANs and AGN1x using
their respective loopback addresses. their respective loopback addresses.
3.1.1. AN with Static Routing 3.1.1. AN with Static Routing
If access static routing is used, ANs are provisioned with the If access static routing is used, ANs are provisioned with the
following static IP routing entries (topology references from following static IP routing entries (topology references from
Section 2 are listed in square brackets): Section 2 are listed in square brackets):
a. [I1, V, U2] - Static default route 0/0 pointing to links a. [I1, V, U2] - Static default route 0/0 pointing to links
connected to AGN1x. Requires support for Inter-area LDP connected to AGN1x. Requires support for Inter-area LDP
[RFC5283]. [RFC5283].
b. [U2] - Static /32 routes pointing to the other AN. Lower b. [U2] - Static /32 routes pointing to the other AN. Lower
preference static default route 0/0 pointing to links connected preference static default route 0/0 pointing to links connected
to the other AN. Requires support for Inter-area LDP [RFC5283]. to the other AN. Requires support for Inter-area LDP [RFC5283].
c. [I, Y] - Static default route 0/0 pointing to links leading c. [I, Y] - Static default route 0/0 pointing to links leading
towards AGN1x. Requires support for Inter-area LDP [RFC5283]. towards AGN1x. Requires support for Inter-area LDP [RFC5283].
d. [I, Y] - Static /32 routes to all ANs in the daisy-chain pointing d. [I, Y] - Static /32 routes to all ANs in the daisy-chain pointing
to links towards those ANs. to links towards those ANs.
e. [I1, V, U2] - Optional - Static /32 routes for specific nodes e. [I1, V, U2] - Optional - Static /32 routes for specific nodes
within Seamless MPLS network, pointing to links connected to within the Seamless MPLS network, pointing to links connected to
AGN1x. AGN1x.
f. [I, Y] - Optional - Static /32 routes for specific nodes within f. [I, Y] - Optional - Static /32 routes for specific nodes within
the Seamless MPLS network, pointing to links leading towards the Seamless MPLS network, pointing to links leading towards
AGN1x. AGN1x.
Upstream AN/AGN1x requests labels over LDP DoD session(s) from The upstream AN/AGN1x requests labels over an LDP DoD session(s) from
downstream AN/AGN1x for configured static routes if those static downstream AN/AGN1x for configured static routes if those static
routes are configured with LDP DoD request policy and if they are routes are configured with an LDP DoD request policy and if they are
pointing to a next-hop selected by routing. It is expected that all pointing to a next hop selected by routing. It is expected that all
configured /32 static routes to be used for LDP DoD are configured configured /32 static routes to be used for LDP DoD are configured
with such policy on AN/AGN1x. with such a policy on an AN/AGN1x.
Downstream AN/AGN1x responds to the Label Request from the upstream The downstream AN/AGN1x responds to the Label Request from the
AN/AGN1x with a Label Mapping if requested route is present in its upstream AN/AGN1x with a label mapping if the requested route is
RIB, and there is a valid label binding from its downstream or it is present in its RIB and there is a valid label binding from its
the egress node. In such case downstream AN/AGN1x installs the downstream neighbor or if it is the egress node. In such a case, the
advertised label as an incoming label in its label table (LIB) and downstream AN/AGN1x installs the advertised label as an incoming
its forwarding table (LFIB). Upstream AN/AGN1x also installs the label in its label information base (LIB) and its label forwarding
received label as an outgoing label in their LIB and LFIB. If the information base (LFIB). The upstream AN/AGN1x also installs the
received label as an outgoing label in its LIB and LFIB. If the
downstream AN/AGN1x does have the route present in its RIB, but does downstream AN/AGN1x does have the route present in its RIB, but does
not have a valid label binding from its downstream, it forwards the not have a valid label binding from its downstream neighbor, it
request to its downstream. forwards the request to its downstream neighbor.
In order to facilitate ECMP and IPFRR LFA local-repair, the upstream In order to facilitate ECMP and IP Fast Reroute (IPFRR) Loop-Free
AN/AGN1x also sends LDP DoD label requests to alternate next-hops per Alternate (LFA) local-repair [RFC5286], the upstream AN/AGN1x also
its RIB, and install received labels as alternate entries in its LIB sends LDP DoD Label Requests to alternate next hops per its RIB, and
and LFIB. installs received labels as alternate entries in its LIB and LFIB.
AGN1x node on the network side can use BGP labeled unicast [RFC3107] The AGN1x on the network side can use BGP labeled IP routes [RFC3107]
in line with the Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. in line with the Seamless MPLS design [SEAMLESS-MPLS]. In such a
In such a case AGN1x will be redistributing its static routes case, AGN1x will redistribute its static routes pointing to local ANs
pointing to local ANs into BGP labeled unicast to facilitate network- into BGP labeled IP routes to facilitate network-to-access traffic
to-access traffic flows. Likewise, to facilitate access-to-network flows. Likewise, to facilitate access-to-network traffic flows,
traffic flows, AGN1x will be responding to access-originated LDP DoD AGN1x will respond to access-originated LDP DoD Label Requests with
label requests with label mappings based on its BGP labeled unicast label mappings based on its BGP labeled IP routes reachability for
reachability for requested FECs. requested FECs.
3.1.2. AN with Access IGP 3.1.2. AN with Access IGP
If access IGP is used, AN(s) advertise their loopbacks over the If access IGP is used, an AN(s) advertises its loopbacks over the
access IGP with configured metrics. AGN1x advertise a default route access IGP with configured metrics. The AGN1x advertises a default
over the access IGP. route over the access IGP.
Routers request labels over LDP DoD session(s) according to their Routers request labels over LDP DoD session(s) according to their
needs for MPLS connectivity (LSPs). In particular if AGNs, as per needs for MPLS connectivity (via Label Switching Paths (LSPs)). In
Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute particular, if AGNs, as per Seamless MPLS design [SEAMLESS-MPLS],
routes from the IGP into BGP labeled unicast [RFC3107], they request redistribute routes from the IGP into BGP labeled IP routes
labels over LDP DoD session(s) for those routes. [RFC3107], they request labels over LDP DoD session(s) for those
routes.
Identically to the static route case, downstream AN/AGN1x responds to Identical to the static route case, the downstream AN/AGN1x responds
the Label Request from the upstream AN/AGN1x with a Label Mapping (if to the Label Request from the upstream AN/AGN1x with a label mapping
the requested route is present in its RIB, and there is a valid label (if the requested route is present in its RIB and there is a valid
binding from its downstream), and installs the advertised label as an label binding from its downstream neighbor), and installs the
incoming label in its LIB and LFIB. Upstream AN/AGN1x also installs advertised label as an incoming label in its LIB and LFIB. The
the received label as an outgoing label in their LIB and LFIB. upstream AN/AGN1x also installs the received label as an outgoing
label in its LIB and LFIB.
Identically to the static route case, in order to facilitate ECMP and Identical to the static route case, in order to facilitate ECMP and
IPFRR LFA local-repair, upstream AN/AGN1x also sends LDP DoD label IPFRR LFA local-repair, the upstream AN/AGN1x also sends LDP DoD
requests to alternate next-hops per its RIB, and installs received Label Requests to alternate next hops per its RIB, and it installs
labels as alternate entries in its LIB and LFIB. received labels as alternate entries in its LIB and LFIB.
AGN1x node on the network side can use BGP labeled unicast [RFC3107] The AGN1x on the network side can use labeled BGP [RFC3107] in line
in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In with Seamless MPLS design [SEAMLESS-MPLS]. In such a case, AGN1x
such case AGN1x will be redistributing routes received over the will redistribute routes received over the access IGP (and pointing
access IGP (and pointing to local ANs), into BGP labeled unicast to to local ANs), into BGP labeled IP routes to facilitate network-to-
facilitate network-to-access traffic flows. Likewise, to facilitate access traffic flows. Likewise, to facilitate access-to-network
access-to-network traffic flows AGN1x will be responding to access traffic flows, the AGN1x will respond to access-originated LDP DoD
originated LDP DoD label requests with label mappings based on its Label Requests with label mappings based on its BGP labeled IP routes
BGP labeled unicast reachability for requested FECs. reachability for requested FECs.
3.2. Service Provisioning and Activation 3.2. Service Provisioning and Activation
Following the initial setup phase described in Section 3.1, a Following the initial setup phase described in Section 3.1, a
specific access node, referred to as AN*, is provisioned with a specific access node, referred to as AN*, is provisioned with a
network service. AN* relies on LDP DoD to request the required MPLS network service. AN* relies on LDP DoD to request the required MPLS
LSP(s) label(s) from downstream AN/AGN1x node(s). Note that LDP DoD LSP(s) label(s) from the downstream AN/AGN1x node(s). Note that LDP
operations are service agnostic, that is, they are the same DoD operations are service agnostic; that is, they are the same
independently of the services provisioned on the AN*. independently of the services provisioned on the AN*.
For illustration purposes two service types are described: MPLS PWE3 For illustration purposes, two service types are described: MPLS PWE3
[RFC4447] service and BGP/MPLS IPVPN [RFC4364]. [RFC4447] service and BGP/MPLS IPVPN [RFC4364].
MPLS PWE3 service - for description simplicity it is assumed that a MPLS PWE3 service: For description simplicity, it is assumed that a
single segment pseudowire is signaled using targeted LDP FEC128 single segment pseudowire is signaled using targeted LDP (tLDP)
(0x80), and it is provisioned with the pseudowire ID and the loopback FEC128 (0x80), and it is provisioned with the pseudowire ID and the
IPv4 address of the destination node. The following IP/MPLS loopback IPv4 address of the destination node. The following IP/MPLS
operations need to be completed on the AN* to successfully establish operations need to be completed on the AN* to successfully establish
such PWE3 service: such PWE3 service:
a. LSP labels for destination /32 FEC (outgoing label) and the local a. LSP labels for destination /32 FEC (outgoing label) and the local
/32 loopback (incoming label) need to be signaled using LDP DoD. /32 loopback (incoming label) need to be signaled using LDP DoD.
b. Targeted LDP session over an associated TCP/IP connection needs b. A tLDP session over an associated TCP/IP connection needs to be
to be established to the PWE3 destination PE. This is triggered established to the PWE3 destination Provider Edge (PE). This is
by either an explicit targeted LDP session configuration on the triggered either by an explicit tLDP session configuration on the
AN* or automatically at the time of provisioning the PWE3 AN* or automatically at the time of provisioning the PWE3
instance. instance.
c. Local and remote PWE3 labels for specific FEC128 PW ID need to be c. Local and remote PWE3 labels for specific FEC128 PW ID need to be
signaled using targeted LDP and PWE3 signaling procedures signaled using tLDP and PWE3 signaling procedures [RFC4447].
[RFC4447].
d. Upon successful completion of the above operations, AN* programs d. Upon successful completion of the above operations, AN* programs
its RIB/LIB and LFIB tables, and activates the MPLS PWE3 service. its RIB/LIB and LFIB tables and activates the MPLS PWE3 service.
Note - only minimum operations applicable to service connectivity Note: Only minimum operations applicable to service connectivity have
have been listed. Other non IP/MPLS connectivity operations that are been listed. Other non-IP/non-MPLS connectivity operations that are
required for successful service provisioning and activation are out required for successful service provisioning and activation are out
of scope in this document. of scope in this document.
BGP/MPLS IPVPN service - for description simplicity it is assumed BGP/MPLS IPVPN service: For description simplicity, it is assumed
that AN* is provisioned with a unicast IPv4 IPVPN service (VPNv4 for that the AN* is provisioned with a unicast IPv4 IPVPN service (VPNv4
short) [RFC4364]. The following IP/MPLS operations need to be for short) [RFC4364]. The following IP/MPLS operations need to be
completed on the AN* to successfully establish VPNv4 service: completed on the AN* to successfully establish VPNv4 service:
a. BGP peering sessions with associated TCP/IP connections need to a. BGP peering sessions with associated TCP/IP connections need to
be established with the remote destination VPNv4 PEs or Route be established with the remote destination VPNv4 PEs or Route
Reflectors. Reflectors.
b. Based on configured BGP policies, VPNv4 BGP NLRIs need to be b. Based on configured BGP policies, VPNv4 BGP Network Layer
exchanged between AN* and its BGP peers. Reachability Information (NLRI) needs to be exchanged between AN*
and its BGP peers.
c. Based on configured BGP policies, VPNv4 routes need to be c. Based on configured BGP policies, VPNv4 routes need to be
installed in the AN* VRF RIB and FIB, with corresponding BGP installed in the AN* VPN Routing and Forwarding (VRF) RIB and
next-hops. FIB, with corresponding BGP next hops.
d. LSP labels for destination BGP next-hop /32 FEC (outgoing label) d. LSP labels for destination BGP next-hop /32 FEC (outgoing label)
and the local /32 loopback (incoming label) need to be signaled and the local /32 loopback (incoming label) need to be signaled
using LDP DoD. using LDP DoD.
e. Upon successful completion of above operations, AN* programs its e. Upon successful completion of above operations, AN* programs its
RIB/LIB and LFIB tables, and activates the BGP/MPLS IPVPN RIB/LIB and LFIB tables, and activates the BGP/MPLS IPVPN
service. service.
Note - only minimum operations applicable to service connectivity Note: Only minimum operations applicable to service connectivity have
have been listed. Other non IP/MPLS connectivity operations that are been listed. Other non-IP/-MPLS connectivity operations that are
required for successful service provisioning are out of scope in this required for successful service provisioning are out of scope in this
document. document.
To establish an LSP for destination /32 FEC for any of the above To establish an LSP for destination /32 FEC for any of the above
services, AN* looks up its local routing table for a matching route, services, AN* looks up its local routing table for a matching route
selects the best next-hop(s) and associated outgoing link(s). and selects the best next hop(s) and associated outgoing link(s).
If a label for this /32 FEC is not already installed based on the If a label for this /32 FEC is not already installed based on the
configured static route with LDP DoD request policy or access IGP RIB configured static route with LDP DoD request policy or access IGP RIB
entry, AN* sends an LDP DoD Label Mapping request. Downstream AN/ entry, AN* sends an LDP DoD label mapping request. A downstream
AGN1x LSR(s) checks its RIB for presence of the requested /32 and AN/AGN1x LSR(s) checks its RIB for presence of the requested /32 and
associated valid outgoing label binding, and if both are present, associated valid outgoing label binding, and if both are present,
replies with its label for this FEC and installs this label as replies with its label for this FEC and installs this label as
incoming in its LIB and LFIB. Upon receiving the Label Mapping the incoming in its LIB and LFIB. Upon receiving the label mapping, the
AN* accepts this label based on the exact route match of advertised AN* accepts this label based on the exact route match of the
FEC and route entry in its RIB or based on the longest match in line advertised FEC and route entry in its RIB or based on the longest
with Inter-area LDP [RFC5283]. If the AN* accepts the label it match in line with Inter-area LDP [RFC5283]. If the AN* accepts the
installs it as an outgoing label in its LIB and LFIB. label, it installs it as an outgoing label in its LIB and LFIB.
In access topologies [V] and [Y], if AN* is dual homed to two AGN1x In access topologies [V] and [Y], if AN* is dual-homed to two AGN1x
and routing entries for these AGN1x are configured as equal cost and routing entries for these AGN1x's are configured as equal-cost
paths, AN* sends LDP DoD label requests to both AGN1x devices and paths, AN* sends LDP DoD Label Requests to both AGN1x devices and
install all received labels in its LIB and LFIB. installs all received labels in its LIB and LFIB.
In order for AN* to implement IPFRR LFA local-repair, AN* also sends In order for AN* to implement IPFRR LFA local-repair, AN* also sends
LDP DoD label requests to alternate next-hops per its RIB, and LDP DoD Label Requests to alternate next hops per its RIB, and
install received labels as alternate entries in its LIB and LFIB. installs received labels as alternate entries in its LIB and LFIB.
When forwarding PWE3 or VPNv4 packets AN* chooses the LSP label based When forwarding PWE3 or VPNv4 packets, AN* chooses the LSP label
on the locally configured static /32 or default route, or default based on the locally configured static /32 or default route or
route signaled via access IGP. If a route is reachable via multiple default route signaled via access IGP. If a route is reachable via
interfaces to AGN1x nodes and the route has multiple equal cost multiple interfaces to AGN1x nodes and the route has multiple equal-
paths, AN* implements Equal Cost Multi-Path (ECMP) functionality. cost paths, AN* implements ECMP functionality. This involves AN*
This involves AN* using hash-based load-balancing mechanism and using a hash-based load-balancing mechanism and sending the PWE3 or
sending the PWE3 or VPNv4 packets in a flow-aware manner with VPNv4 packets in a flow-aware manner with appropriate LSP labels via
appropriate LSP labels via all equal cost links. all equal-cost links.
ECMP mechanism is applicable in an equal manner to parallel links The ECMP mechanism is applicable in an equal manner to parallel links
between two network elements and multiple paths towards the between two network elements and multiple paths towards the
destination. The traffic demand is distributed over the available destination. The traffic demand is distributed over the available
paths. paths.
AGN1x node on the network side can use BGP labeled unicast [RFC3107] The AGN1x on the network side can use labeled BGP [RFC3107] in line
in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In with Seamless MPLS design [SEAMLESS-MPLS]. In such a case, the AGN1x
such case AGN1x will be redistributing its static routes (or routes will redistribute its static routes (or routes received from the
received from the access IGP) pointing to local ANs into BGP labeled access IGP) pointing to local ANs into BGP labeled IP routes to
unicast to facilitate network-to-access traffic flows. Likewise, to facilitate network-to-access traffic flows. Likewise, to facilitate
facilitate access-to-network traffic flows AGN1x will be responding access-to-network traffic flows, the AGN1x will respond to access-
to access originated LDP DoD label requests with label mappings based originated LDP DoD Label Requests with label mappings based on its
on its BGP labeled unicast reachability for requested FECs. BGP labeled IP routes reachability for requested FECs.
3.3. Service Changes and Decommissioning 3.3. Service Changes and Decommissioning
Whenever AN* service gets decommissioned or changed and connectivity Whenever the AN* service gets decommissioned or changed and
to specific destination is not longer required, the associated MPLS connectivity to a specific destination is no longer required, the
LSP label resources are to be released on AN*. associated MPLS LSP label resources are to be released on AN*.
MPLS PWE3 service - if the PWE3 service gets decommissioned and it is MPLS PWE3 service: If the PWE3 service gets decommissioned and it is
the last PWE3 to a specific destination node, the targeted LDP the last PWE3 to a specific destination node, the tLDP session is no
session is not longer needed and is to be terminated (automatically longer needed and is to be terminated (automatically or by
or by configuration). The MPLS LSP(s) to that destination is no configuration). The MPLS LSP(s) to that destination is no longer
longer needed either. needed either.
BGP/MPLS IPVPN service - deletion of a specific VPNv4 (VRF) instance, BGP/MPLS IPVPN service: Deletion of a specific VPNv4 (VRF) instance
local or remote re-configuration can result in specific BGP next- via local or remote reconfiguration can result in a specific BGP next
hop(s) being no longer needed. The MPLS LSP(s) to that destination hop(s) no longer being needed. The MPLS LSP(s) to that destination
is no longer needed either. is no longer needed either.
In all of the above cases the following LDP DoD related operations In all of the above cases, the following operations related to LDP
apply: DoD apply:
o If the /32 FEC label for the aforementioned destination node was o If the /32 FEC label for the aforementioned destination node was
originally requested based on either tLDP session configuration originally requested based on either tLDP session configuration
and default route or required BGP next-hop and default route, AN* and default route or required BGP next hop and default route, AN*
deletes the label from its LIB and LFIB, and release it from deletes the label from its LIB and LFIB, and releases it from the
downstream AN/AGN1x by using LDP DoD procedures. downstream AN/AGN1x by using LDP DoD procedures.
o If the /32 FEC label was originally requested based on the static o If the /32 FEC label was originally requested based on the static
/32 route configuration with LDP DoD request policy, the label is /32 route configuration with LDP DoD request policy, the label is
retained by AN*. retained by AN*.
3.4. Service Failure 3.4. Service Failure
A service instance can stop being operational due to a local or A service instance can stop being operational due to a local or
remote service failure event. remote service failure event.
In general, unless the service failure event modifies required MPLS In general, unless the service failure event modifies required MPLS
connectivity, there is no impact on the LDP DoD operation. connectivity, there is no impact on the LDP DoD operation.
If the service failure event does modify the required MPLS If the service failure event does modify the required MPLS
connectivity, LDP DoD operations apply as described in Section 3.2 connectivity, LDP DoD operations apply as described in Sections 3.2
and Section 3.3. and 3.3.
3.5. Network Transport Failure 3.5. Network Transport Failure
A number of different network events can impact services on AN*. The A number of different network events can impact services on AN*. The
following sections describe network event types that impact LDP DoD following sections describe network event types that impact LDP DoD
operation on AN and AGN1x nodes. operation on AN and AGN1x nodes.
3.5.1. General Notes 3.5.1. General Notes
If service on any of the ANs is affected by any network failure and If service on any of the ANs is affected by any network failure and
there is no network redundancy, the service goes into a failure there is no network redundancy, the service goes into a failure
state. When the network failure is recovered from, the service is to state. Upon recovery from network failure, the service is to be
be re-established automatically. re-established automatically.
The following additional LDP-related functions need to be supported The following additional LDP-related functions need to be supported
to comply with Seamless MPLS [I-D.ietf-mpls-seamless-mpls] fast to comply with Seamless MPLS [SEAMLESS-MPLS] fast service restoration
service restoration requirements as follows: requirements:
a. Local-repair - AN and AGN1x support local-repair for adjacent a. Local-repair: AN and AGN1x support local-repair for adjacent link
link or node failure for access-to-network, network-to-access and or node failure for access-to-network, network-to-access, and
access-to-access traffic flows. Local-repair is to be access-to-access traffic flows. Local-repair is to be
implemented by using either IPFRR LDP LFA, simple ECMP or primary implemented by using either IPFRR LDP LFA, simple ECMP, or
/backup switchover upon failure detection. primary/backup switchover upon failure detection.
b. LDP session protection - LDP sessions are configured with LDP b. LDP session protection: LDP sessions are configured with LDP
session protection to avoid delay upon the recovery from link session protection to avoid delay upon the recovery from link
failure. LDP session protection ensures that FEC label binding failure. LDP session protection ensures that FEC label binding
is maintained in the control plane as long as LDP session stays is maintained in the control plane as long as the LDP session
up. stays up.
c. IGP-LDP synchronization - If access IGP is used, LDP sessions c. IGP-LDP synchronization: If access IGP is used, LDP sessions
between ANs, and between ANs and AGN1x, are configured with IGP- between ANs, and between ANs and AGN1x, are configured with IGP-
LDP synchronization to avoid unnecessary traffic loss in case the LDP synchronization to avoid unnecessary traffic loss in case the
access IGP converged before LDP and there is no LDP label binding access IGP converged before LDP and there is no LDP label binding
to the downstream best next-hop. to the best downstream next hop.
3.5.2. AN Node Failure
AN node fails and all links to adjacent nodes go down. 3.5.2. AN Failure
Adjacent AN/AGN1x nodes remove all routes pointing to the failed If the AN fails, adjacent AN/AGN1x nodes remove all routes pointing
link(s) from their RIB tables (including /32 loopback belonging to to the failed node from their RIB tables (including /32 loopback
the failed AN and any other routes reachable via the failed AN). belonging to the failed AN and any other routes reachable via the
This in turn triggers the removal of associated outgoing /32 FEC failed AN). In turn, this triggers the removal of associated
labels from their LIB and LFIB tables. outgoing /32 FEC labels from their LIB and LFIB tables.
If access IGP is used, the AN node failure will be propagated via IGP If access IGP is used, the AN failure will be propagated via IGP link
link updates across the access topology. updates across the access topology.
If a specific /32 FEC(s) is not reachable anymore from those AN/ If a specific /32 FEC(s) is no longer reachable from those
AGN1x, they also send LDP Label Withdraw to their upstream LSRs to ANs/AGN1x's, they also send LDP Label Withdraw messages to their
notify about the failure, and remove the associated incoming label(s) upstream LSRs to notify them about the failure, and remove the
from their LIB and LFIB tables. Upstream LSRs upon receiving Label associated incoming label(s) from their LIB and LFIB tables.
Withdraw remove the signaled labels from their LIB/LFIB tables, and Upstream LSRs, upon receiving a Label Withdraw, remove the signaled
propagate LDP Label Withdraw across their upstream LDP DoD sessions. labels from their LIB/LFIB tables, and propagate LDP Label Withdraws
across their upstream LDP DoD sessions.
In [U] topology there may be an alternative path to routes previously In the [U] topology, there may be an alternative path to routes
reachable via the failed AN node. In this case adjacent AN/AGN1x previously reachable via the failed AN. In this case, adjacent
invoke local-repair (IPFRR LFA, ECMP) and switchover to alternate AN/AGN1x pairs invoke local-repair (IPFRR LFA, ECMP) and switch over
next-hop to reach those routes. to an alternate next hop to reach those routes.
AGN1x gets notified about the AN failure via either access IGP (if AGN1x is notified about the AN failure via access IGP (if used)
used) and/or cascaded LDP DoD label withdraw(s). AGN1x implements and/or cascaded LDP DoD Label Withdraw(s). AGN1x implements all
all relevant global-repair IP/MPLS procedures to propagate the AN relevant global-repair IP/MPLS procedures to propagate the AN failure
failure towards the core network. This involves removing associated towards the core network. This involves removing associated routes
routes (in access IGP case) and labels from its LIB and LFIB tables, (in the access IGP case) and labels from its LIB and LFIB tables, and
and propagating the failure on the network side using BGP-LU and/or propagating the failure on the network side using labeled BGP and/or
core IGP/LDP-DU procedures. core IGP/LDP DU procedures.
Upon AN coming back up, adjacent AN/AGN1x nodes automatically add Upon the AN coming back up, adjacent AN/AGN1x nodes automatically add
routes pointing to recovered links based on the configured static routes pointing to recovered links based on the configured static
routes or access IGP adjacency and link state updates. This is then routes or access IGP adjacency and link state updates. This is then
followed by LDP DoD label signaling and subsequent binding and followed by LDP DoD label signaling and subsequent binding and
installation of labels in LIB and LFIB tables. installation of labels in LIB and LFIB tables.
3.5.3. AN/AGN Link Failure 3.5.3. AN/AGN Link Failure
Depending on the access topology and the failed link location Depending on the access topology and the failed link location,
different cases apply to the network operation after AN link failure different cases apply to the network operation after AN link failure
(topology references from Section 2 in square brackets): (topology references from Section 2 in square brackets):
a. [all] - link failed, but at least one ECMP parallel link remains a. [all] - link failed, but at least one ECMP parallel link remains.
- nodes on both sides of the failed link stop using the failed Nodes on both sides of the failed link stop using the failed link
link immediately (local-repair), and keep using the remaining immediately (local-repair) and keep using the remaining ECMP
ECMP parallel links. parallel links.
b. [I1, I, Y] - link failed, and there are no ECMP or alternative b. [I1, I, Y] - link failed, and there are no ECMP or alternative
links and paths - nodes on both sides of the failed link remove links and paths. Nodes on both sides of the failed link remove
routes pointing to the failed link immediately from the RIB, routes pointing to the failed link immediately from the RIB,
remove associated labels from their LIB and LFIB tabels, and send remove associated labels from their LIB and LFIB tables, and send
LDP label withdraw(s) to their upstream LSRs. LDP Label Withdraw(s) to their upstream LSRs.
c. [U2, U, V, Y] - link failed, but at least one ECMP or alternate c. [U2, U, V, Y] - link failed, but at least one ECMP or alternate
path remains - AN/AGN1x node stops using the failed link and path remains. The AN/AGN1x node stops using the failed link and
immediately switchover (local-repair) to the remaining ECMP path immediately switches over (local-repair) to the remaining ECMP
or alternate path. AN/AGN1x removes affected next-hops and path or alternate path. The AN/AGN1x removes affected next hops
labels from its tables and invoke LDP Label Withdraw as per point and labels. If there is an AGN1x terminating the failed link, it
(a) above. If there is an AGN1x node terminating the failed immediately removes routes pointing to the failed link from the
link, it removes routes pointing to the failed link immediately RIB, removes any associated labels from the LIB and LFIB tables,
from the RIB, remove associated labels from their LIB and LFIB and propagates the failure on the network side using labeled BGP
tabels, and propagate the failure on the network side using BGP- and/or core IGP procedures.
LU and/or core IGP procedures.
If access IGP is used AN/AGN1x link failure will be propagated via If access IGP is used, AN/AGN1x link failure will be propagated via
IGP link updates across the access topology. IGP link updates across the access topology.
LDP DoD will also propagate the link failure by sending label LDP DoD will also propagate the link failure by sending Label
withdraws to upstream AN/AGN1x nodes, and Label Release messages Withdraws to upstream AN/AGN1x nodes, and Label Release messages to
downstream AN/AGN1x nodes. downstream AN/AGN1x nodes.
3.5.4. AGN Node Failure 3.5.4. AGN Failure
AGN1x fails and all links to adjacent access nodes go down.
Depending on the access topology, following cases apply to the If an AGN1x fails adjacent access then, depending on the access
network operation after AGN1x node failure (topology references from topology, the following cases apply to the network operation
Section 2 in square brackets): (topology references from Section 2 are shown in square brackets):
a. [I1, I] - ANs are isolated from the network - AN adjacent to the a. [I1, I] - ANs are isolated from the network - An AN adjacent to
failure removes routes pointing to the failed AGN1x node the failure immediately removes routes pointing to the failed
immediately from the RIB, removes associated labels from their AGN1x from the RIB, removes associated labels from the LIB and
LIB and LFIB tabels, and sends LDP label withdraw(s) to their LFIB tables, and sends LDP Label Withdraw message(s) to its
upstream LSRs. If access IGP is used, an IGP link update is upstream neighbors. If access IGP is used, an IGP link update is
sent. sent.
b. [U2, U, V, Y] - at least one ECMP or alternate path remains - AN b. [U2, U, V, Y] - at least one ECMP or alternate path remains. AN
adjacent to failed AGN1x stops using the failed link and adjacent to failed AGN1x stops using the failed link and
immediately switchover (local-repair) to the remaining ECMP path immediately switches over (local-repair) to the remaining ECMP
or alternate path. AN removes affected routes and labels from path or alternate path by following LDP [RFC5036] procedures.
its tables and invoke LDP Label Withdraw as per point (a) above. (Appendix A.1.7 "Detect Change in FEC Next Hop")
Network side procedures for handling AGN1x node failure have been
described in Seamless MPLS [I-D.ietf-mpls-seamless-mpls].
3.5.5. AGN Network-side Reachability Failure Network-side procedures for handling AGN1x failure have been
described in Seamless MPLS [SEAMLESS-MPLS].
AGN1x loses network reachability to a specific destination or set of 3.5.5. AGN Network-Side Reachability Failure
network-side destinations.
In such event AGN1x sends LDP Label Withdraw messages to its upstream If AGN1x loses network reachability to a specific destination or set
ANs, withdrawing labels for all affected /32 FECs. Upon receiving of network-side destinations, AGN1x sends LDP Label Withdraw messages
those messages ANs remove those labels from their LIB and LFIB to its upstream ANs, withdrawing labels for all affected /32 FECs.
tables, and use alternative LSPs instead if available as part of Upon receiving those messages, ANs remove those labels from their LIB
global-repair. In turn ANs also send Label Withdraw messages for and LFIB tables, and use alternative LSPs instead (if available) as
affected /32 FECs to their upstream ANs. part of global-repair.
If access IGP is used, and AGN1x gets completely isolated from the If access IGP is used, and AGN1x gets completely isolated from the
core network, it stops advertising the default route 0/0 into the core network, it stops advertising the default route 0/0 into the
access IGP. access IGP.
4. LDP DoD Procedures 4. LDP DoD Procedures
Label Distribution Protocol is specified in [RFC5036], and all LDP All LDP Downstream-on-Demand implementations follow the Label
Downstream-on-Demand implementations follow [RFC5036] specification. Distribution Protocol as specified in [RFC5036]. This section does
This section does not update [RFC5036] procedures, but illustrates not update [RFC5036] procedures, but illustrates LDP DoD operations
LDP DoD operations in the context of use cases identified in in the context of use cases identified in Section 3 in this document,
Section 3 in this document, for information only. for information only.
In the MPLS architecture [RFC3031], network traffic flows from In the MPLS architecture [RFC3031], network traffic flows from the
upstream to downstream LSR. The use cases in this document rely on upstream LSR to the downstream LSR. The use cases in this document
the downstream assignment of labels, where labels are assigned by the rely on the downstream assignment of labels, where labels are
downstream LSR and signaled to the upstream LSR as shown in Figure 7. assigned by the downstream LSR and signaled to the upstream LSR as
shown in Figure 7.
+----------+ +------------+ +----------+ +------------+
| upstream | | downstream | | upstream | | downstream |
------+ LSR +------+ LSR +---- ------+ LSR +------+ LSR +----
traffic | | | | address traffic | | | | address
source +----------+ +------------+ (/32 for IPv4) source +----------+ +------------+ (/32 for IPv4)
traffic traffic
label distribution for IPv4 FEC destination label distribution for IPv4 FEC destination
<------------------------- <-------------------------
traffic flow traffic flow
-------------------------> ------------------------->
Figure 7: LDP label assignment direction Figure 7: LDP Label Assignment Direction
4.1. LDP Label Distribution Control and Retention Modes 4.1. LDP Label Distribution Control and Retention Modes
LDP protocol specification [RFC5036] defines two modes for label The LDP specification [RFC5036] defines two modes for label
distribution control, following the definitions in MPLS architecture distribution control, following the definitions in the MPLS
[RFC3031]: architecture [RFC3031]:
o Independent mode - an LSR recognizes a particular FEC and makes a o Independent mode: An LSR recognizes a particular FEC and makes a
decision to bind a label to the FEC independently from decision to bind a label to the FEC independently from
distributing that label binding to its label distribution peers. distributing that label binding to its label distribution peers.
A new FEC is recognized whenever a new route becomes valid on the A new FEC is recognized whenever a new route becomes valid on the
LSR. LSR.
o Ordered mode - an LSR needs to bind a label to a particular FEC if o Ordered mode: An LSR needs to bind a label to a particular FEC if
it knows how to forward packets for that FEC ( i.e. it has a route it knows how to forward packets for that FEC (i.e., it has a route
corresponding to that FEC ) and if it has already received at corresponding to that FEC) and if it has already received at least
least one Label Request message from an upstream LSR. one Label Request message from an upstream LSR.
Using independent label distribution control with LDP DoD and access Using independent label distribution control with LDP DoD and access
static routing would prevent the access LSRs from propagating label static routing would prevent the access LSRs from propagating label
binding failure along the access topology, making it impossible for binding failure along the access topology, making it impossible for
upstream LSR to be notified about the downstream failure and for an an upstream LSR to be notified about the downstream failure and for
application using the LSP to switchover to an alternate path, even if an application using the LSP to switch over to an alternate path,
such a path exists. even if such a path exists.
LDP protocol specification [RFC5036] defines two modes for label The LDP specification [RFC5036] defines two modes for label
retention, following the definitions in MPLS architecture [RFC3031]: retention, following the definitions in the MPLS architecture
[RFC3031]:
o Conservative mode - If operating in Downstream on Demand mode, an o Conservative label retention mode: If operating in DoD mode, an
LSR will request label mappings only from the next hop LSR LSR will request label mappings only from the next-hop LSR
according to routing. The main advantage of the conservative mode according to routing. The main advantage of the conservative
is that only the labels that are required for the forwarding of label retention mode is that only the labels that are required for
data are allocated and maintained. This is particularly important the forwarding of data are allocated and maintained. This is
in LSRs where the label space is inherently limited, such as in an particularly important in LSRs where the label space is inherently
ATM switch. A disadvantage of the conservative mode is that if limited, such as in an ATM switch. A disadvantage of the
routing changes the next hop for a given destination, a new label conservative label retention mode is that if routing changes the
must be obtained from the new next hop before labeled packets can next hop for a given destination, a new label must be obtained
be forwarded. from the new next hop before labeled packets can be forwarded.
o Liberal mode - When operating in Downstream on Demand mode with o Liberal label retention mode: When operating in DoD mode with
Liberal Label retention, an LSR might choose to request label liberal label retention mode, an LSR might choose to request label
mappings for all known prefixes from all peer LSRs. The main mappings for all known prefixes from all peer LSRs. The main
advantage of the Liberal Label retention mode is that reaction to advantage of the liberal label retention mode is that reaction to
routing changes can be quick because labels already exist. The routing changes can be quick because labels already exist. The
main disadvantage of the liberal mode is that unneeded label main disadvantage of the liberal label retention mode is that
mappings are distributed and maintained. unneeded label mappings are distributed and maintained.
Note that the conservative label retention mode would prevent LSRs Note that the conservative label retention mode would prevent LSRs
from requesting and maintaining label mappings for any backup routes from requesting and maintaining label mappings for any backup routes
that are not used for forwarding. This in turn would prevent the that are not used for forwarding. In turn, this would prevent the
access LSRs (AN and AGN1x nodes) from implementing any local access LSRs (AN and AGN1x nodes) from implementing any local
protection schemes that rely on using alternate next-hops in case of protection schemes that rely on using alternate next hops in case of
the primary next-hop failure. Such schemes include IPFRR LFA if the primary next-hop failure. Such schemes include IPFRR LFA if
access IGP is used, or a primary and backup static route access IGP is used, or a primary and backup static route
configuration. Using LDP DoD in combination with liberal retention configuration. Using LDP DoD in combination with liberal label
mode allows the LSR to request labels for the specific FEC from retention mode allows the LSR to request labels for the specific FEC
primary next-hop LSR(s) and the alternate next-hop LSR(s) for this from primary next-hop LSR(s) and the alternate next-hop LSR(s) for
FEC. this FEC.
Note that even though LDP DoD operates in a liberal retention mode, Note that even though LDP DoD operates in a liberal label retention
if used with access IGP and if no LFA exists, the LDP DoD will mode, if used with access IGP and if no LFA exists, the LDP DoD will
introduce additional delay in traffic restoration as the labels for introduce additional delay in traffic restoration as the labels for
the new next-hop will get requested only after the access IGP the new next hop will be requested only after the access IGP
convergence. convergence.
Adhering to the overall design goals of Seamless MPLS Adhering to the overall design goals of Seamless MPLS
[I-D.ietf-mpls-seamless-mpls], specifically achieving a large network [SEAMLESS-MPLS], specifically achieving a large network scale without
scale without compromising fast service restoration, all access LSRs compromising fast service restoration, all access LSRs (AN and AGN1x
(AN and AGN1x nodes) use LDP DoD advertisement mode with: nodes) use LDP DoD advertisement mode with:
o Ordered label distribution control - enables propagation of label o Ordered label distribution control: enables propagation of label
binding failure within the access topology. binding failure within the access topology.
o Liberal label retention - enables pre-programming of alternate o Liberal label retention mode: enables pre-programming of alternate
next-hops with associated FEC labels. next hops with associated FEC labels.
In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an In Seamless MPLS [SEAMLESS-MPLS], an AGN1x acts as an access ABR
access ABR connecting access and metro domains. To enable failure connecting access and metro domains. To enable failure propagation
propagation between those domains, access ABR implements ordered between those domains, the access ABR implements ordered label
label distribution control when redistributing routes/FEC between the distribution control when redistributing routes/FECs between the
access-side (using LDP DoD and static or access IGP) and the network- access side (using LDP DoD and static or access IGP) and the network
side ( using BGP labeled unicast [RFC3107] or core IGP with LDP side (using labeled BGP [RFC3107] or core IGP with LDP Downstream
Downstream Unsolicited label advertisement. Unsolicited label advertisements).
4.2. LDP DoD Session Negotiation 4.2. LDP DoD Session Negotiation
Access LSR/ABR propose the Downstream-on-Demand label advertisement An access LSR/ABR proposes the DoD label advertisement by setting the
by setting "A" value to 1 in the Common Session Parameters TLV of the "A" value to 1 in the Common Session Parameters TLV of the
Initialization message. The rules for negotiating the label Initialization message. The rules for negotiating the label
advertisement mode are specified in LDP protocol specification advertisement mode are specified in the LDP specification [RFC5036].
[RFC5036].
To establish a Downstream-on-Demand session between the two access To establish a DoD session between the two access LSR/ABRs, both
LSR/ABRs, both propose the Downstream-on-Demand label advertisement propose the DoD label advertisement mode in the Initialization
mode in the Initialization message. If the access LSR only supports message. If the access LSR only supports LDP DoD and the access ABR
LDP DoD and the access ABR proposes Downstream Unsolicited mode, the proposes the Downstream Unsolicited mode, the access LSR sends a
access LSR sends a Notification message with status "Session Rejected Notification message with status "Session Rejected/Parameters
/Parameters Advertisement Mode" and then close the LDP session as Advertisement Mode" and then closes the LDP session as specified in
specified in LDP protocol specification [RFC5036]. the LDP specification [RFC5036].
If an access LSR is acting in an active role, it re-attempts the LDP If an access LSR is acting in an active role, it re-attempts the LDP
session immediately. If the access LSR receives the same Downstream session immediately. If the access LSR receives the same Downstream
Unsolicited mode again, it follows the exponential backoff algorithm Unsolicited mode again, it follows the exponential backoff algorithm
as defined in the LDP protocol specification [RFC5036] with delay of as defined in the LDP specification [RFC5036] with a delay of 15
15 seconds and subsequent delays growing to a maximum delay of 2 seconds and subsequent delays growing to a maximum delay of 2
minutes. minutes.
In case a PWE3 service is required between the adjacent access LSR/ In case a PWE3 service is required between the adjacent access
ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the same LSR/ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the
LDP session is used for PWE3 FECs. Even if LDP DoD label same LDP session is used for PWE3 FECs. Even if the LDP DoD label
advertisement has been negotiated for IPv4 and IPv6 LDP FECs as advertisement has been negotiated for IPv4 and IPv6 LDP FECs as
described earlier, LDP session uses Downstream Unsolicited label described earlier, the LDP session uses a Downstream Unsolicited
advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447]. label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447].
4.3. Label Request Procedures 4.3. Label Request Procedures
4.3.1. Access LSR/ABR Label Request 4.3.1. Access LSR/ABR Label Request
Upstream access LSR/ABR will request label bindings from adjacent The upstream access LSR/ABR will request label bindings from an
downstream access LSR/ABR based on the following trigger events: adjacent downstream access LSR/ABR based on the following trigger
events:
a. Access LSR/ABR is configured with /32 static route with LDP DoD a. An access LSR/ABR is configured with /32 static route with LDP
Label Request policy in line with initial network setup use case DoD Label Request policy in line with the initial network setup
described in Section 3.1. use case described in Section 3.1.
b. Access LSR/ABR is configured with a service in line with service b. An access LSR/ABR is configured with a service in line with
use cases described in Section 3.2 and Section 3.3. service use cases described in Sections 3.2 and 3.3.
c. Configuration with access static routes - Access LSR/ABR link to c. Configuration with access static routes: An access LSR/ABR link
adjacent node comes up and LDP DoD session is established. In to an adjacent node comes up, and an LDP DoD session is
this case access LSR sends Label Request messages for all /32 established. In this case, the access LSR sends Label Request
static routes configured with LDP DoD policy and all /32 routes messages for all /32 static routes configured with an LDP DoD
related to provisioned services that are covered by default policy and all /32 routes related to provisioned services that
route. are covered by the default route.
d. Configuration with access IGP - Access LSR/ABR link to adjacent d. Configuration with access IGP: An access LSR/ABR link to an
node comes up and LDP DoD session is established. In this case adjacent node comes up, and an LDP DoD session is established.
access LSR sends Label Request messages for all /32 routes In this case, the access LSR sends Label Request messages for all
learned over the access IGP and all /32 routes related to /32 routes learned over the access IGP and all /32 routes related
provisioned services that are covered by access IGP routes. to provisioned services that are covered by access IGP routes.
e. In all above cases requests are sent to next-hop LSR(s) and e. In all above cases, requests are sent to any next-hop LSRs and
alternate LSR(s). alternate LSRs.
Downstream access LSR/ABR will respond with Label Mapping message The downstream access LSR/ABR will respond with a Label Mapping
with a non-null label if any of the below conditions are met: message with a non-null label if any of the below conditions are met:
a. Downstream access LSR/ABR - requested FEC is an IGP or static a. Downstream access LSR/ABR: The requested FEC is an IGP or static
route and there is an LDP label already learnt from the next- route, and there is an LDP label already learned from the next-
next-hop downstream LSR (by LDP DoD or LDP DU). If there is no next-hop downstream LSR (by LDP DoD or LDP DU). If there is no
label for the requested FEC and there is an LDP DoD session to label for the requested FEC and there is an LDP DoD session to
the next-next-hop downstream LSR, downstream LSR sends a Label the next-next-hop downstream LSR, the downstream LSR sends a
Request message for the same FEC to the next-next-hop downstream Label Request message for the same FEC to the next-next-hop
LSR. In such case downstream LSR will respond back to the downstream LSR. In such a case, the downstream LSR will respond
requesting upstream access LSR only after getting a label from back to the requesting upstream access LSR only after getting a
the next-next-hop downstream LSR peer. label from the next-next-hop downstream LSR peer.
b. Downstream access ABR only - requested FEC is a BGP labelled b. Downstream access ABR only: The requested FEC is a BGP labeled IP
unicast route [RFC3107] and this BGP route is the best selected routes [RFC3107], and this BGP route is the best selected for
for this FEC. this FEC.
Downstream access LSR/ABR can respond with a Label Mapping with The downstream access LSR/ABR can respond with a label mapping with
explicit-null or implicit-null label if it is acting as an egress for an explicit-null or implicit-null label if it is acting as an egress
the requested FEC, or it can respond with "No Route" notification if for the requested FEC, or it can respond with a "No Route"
no route exists. notification if no route exists.
4.3.2. Label Request Retry 4.3.2. Label Request Retry
Following LDP specification LDP specification [RFC5036], if an access Following the LDP specification [RFC5036], if an access LSR/ABR
LSR/ABR receives a "No route" Notification in response to its Label receives a "No Route" notification in response to its Label Request
Request message, it retries using an exponential backoff algorithm message, it retries using an exponential backoff algorithm similar to
similar to the backoff algoritm mentioned in the LDP session the backoff algorithm mentioned in the LDP session negotiation
negotiation described in Section 4.2. described in Section 4.2.
If there is no response to the sent Label Request message, the LDP If there is no response to the Label Request message sent, the LDP
specification [RFC5036] (section A.1.1, page# 100) states that the specification [RFC5036] (Section A.1.1) states that the LSR does not
LSR does not send another request for the same label to the peer and send another request for the same label to the peer and mandates that
mandates that a duplicate Label Request is considered a protocol a duplicate Label Request be considered a protocol error and be
error and is dropped by the receiving LSR by sending a Notification dropped by the receiving LSR by sending a Notification message.
message.
Thus, if there is no response from the downstream peer, the access Thus, if there is no response from the downstream peer, the access
LSR/ABR does not send a duplicate Label Request message again. LSR/ABR does not send a duplicate Label Request message.
If the static route corresponding to the FEC gets deleted or if the If the static route corresponding to the FEC gets deleted or if the
DoD request policy is modified to reject the FEC before receiving the DoD request policy is modified to reject the FEC before receiving the
Label Mapping message, then the access LSR/ABR sends a Label Abort Label Mapping message, then the access LSR/ABR sends a Label Abort
message to the downstream LSR. message to the downstream LSR.
To address the case of slower convergence resulting from described To address the case of slower convergence resulting from described
LDP behavior in line with LDP specification [RFC5036], a new LDP TLV LDP behavior in line with the LDP specification [RFC5036], a new LDP
extension is proposed and described in Section 5. TLV extension is proposed and described in Section 5.
4.4. Label Withdraw 4.4. Label Withdraw
If an MPLS label on the downstream access LSR/ABR is no longer valid, If an MPLS label on the downstream access LSR/ABR is no longer valid,
the downstream access LSR/ABR withdraws this FEC/label binding from the downstream access LSR/ABR withdraws this FEC/label binding from
the upstream access LSR/ABR with the Label Withdraw Message [RFC5036] the upstream access LSR/ABR with the Label Withdraw message [RFC5036]
with a specified label TLV or with an empty label TLV. with a specified label TLV or with an empty label TLV.
Downstream access LSR/ABR withdraws a label for specific FEC in the The downstream access LSR/ABR withdraws a label for a specific FEC in
following cases: the following cases:
a. If LDP DoD ingress label is associated with an outgoing label a. If an LDP DoD ingress label is associated with an outgoing label
assigned by BGP labelled unicast route, and this route is assigned by a labeled BGP route and this route is withdrawn.
withdrawn.
b. If LDP DoD ingress label is associated with an outgoing label b. If an LDP DoD ingress label is associated with an outgoing label
assigned by LDP (DoD or DU) and the IGP route is withdrawn from assigned by LDP (DoD or DU), and the IGP route is withdrawn from
the RIB or downstream LDP session is lost. the RIB or the downstream LDP session is lost.
c. If LDP DoD ingress label is associated with an outgoing label c. If an LDP DoD ingress label is associated with an outgoing label
assigned by LDP (DoD or DU) and the outgoing label is withdrawn assigned by LDP (DoD or DU) and the outgoing label is withdrawn
by the downstream LSR. by the downstream LSR.
d. If LDP DoD ingress label is associated with an outgoing label d. If an LDP DoD ingress label is associated with an outgoing label
assigned by LDP (DoD or DU), route next-hop changed and assigned by LDP (DoD or DU), the next hop in the route has
changed, and
* there is no LDP session to the new next-hop. To minimize * there is no LDP session to the new next hop. To minimize the
probability of this, the access LSR/ABR implements LDP-IGP probability of this, the access LSR/ABR implements LDP-IGP
synchronization procedures as specified in [RFC5443]. synchronization procedures as specified in [RFC5443].
* there is an LDP session but no label from downstream LSR. See * there is an LDP session but no label from a downstream LSR.
note below. See note below.
e. If access LSR/ABR is configured with a policy to reject exporting e. If an access LSR/ABR is configured with a policy to reject
label mappings to upstream LSR. exporting label mappings to an upstream LSR.
The upstream access LSR/ABR responds to the Label Withdraw Message The upstream access LSR/ABR responds to the Label Withdraw message
with the Label Release Message [RFC5036]. with the Label Release message [RFC5036].
After sending Label Release message to downstream access LSR/ABR, the After sending the Label Release message to the downstream access
upstream access LSR/ABR resends Label Request message, assuming LSR/ABR, the upstream access LSR/ABR resends the Label Request
upstream access LSR/ABR still requires the label. message, assuming the upstream access LSR/ABR still requires the
label.
Downstream access LSR/ABR withdraws a label if the local route The downstream access LSR/ABR withdraws a label if the local route
configuration (e.g. /32 loopback) is deleted. configuration (e.g., /32 loopback) is deleted.
Note: For any events inducing next hop change, downstream access LSR/ Note: For any events inducing next-hop change, a downstream access
ABR is to attempt to converge the LSP locally before withdrawing the LSR/ABR attempts to converge the LSP locally before withdrawing the
label from an upstream access LSR/ABR. For example if the next-hop label from an upstream access LSR/ABR. For example, if the next hop
changes for a particular FEC and if the new next-hop allocates labels changes for a particular FEC and if the new next hop allocates labels
by LDP DoD session, then the downstream access LSR/ABR sends a Label by the LDP DoD session, then the downstream access LSR/ABR sends a
Request on the new next-hop session. If downstream access LSR/ABR Label Request on the new next-hop session. If the downstream access
doesn't get Label Mapping for some duration, then and only then LSR/ABR doesn't get a label mapping for some duration, then and only
downstream access LSR/ABR withdraws the upstream label. then does the downstream access LSR/ABR withdraw the upstream label.
4.5. Label Release 4.5. Label Release
If an access LSR/ABR does not need any longer a label for a FEC, it If an access LSR/ABR no longer needs a label for a FEC, it sends a
sends a Label Release Message [RFC5036] to the downstream access LSR/ Label Release message [RFC5036] to the downstream access LSR/ABR with
ABR with or without the label TLV. or without the label TLV.
If upstream access LSR/ABR receives an unsolicited Label Mapping on If an upstream access LSR/ABR receives an unsolicited label mapping
DoD session, they release the label by sending Label Release message. on a DoD session, it releases the label by sending a Label Release
message.
Access LSR/ABR sends a Label Release message to the downstream LSR in The access LSR/ABR sends a Label Release message to the downstream
the following cases: LSR in the following cases:
a. If it receives a Label Withdraw from the downstream access LSR/ a. If it receives a Label Withdraw from the downstream access
ABR. LSR/ABR.
b. If the /32 static route with LDP DoD Label Request policy is b. If the /32 static route with LDP DoD Label Request policy is
deleted. deleted.
c. If the service gets decommissioned and there is no corresponding c. If the service gets decommissioned and there is no corresponding
/32 static route with LDP DoD Label Request policy configured. /32 static route with LDP DoD Label Request policy configured.
d. If the route next-hop changed, and the label does not point to d. If the next hop in the route has changed and the label does not
the best or alternate next-hop. point to the best or alternate next hop.
e. If it receives a Label Withdraw from a downstream DoD session. e. If it receives a Label Withdraw from a downstream DoD session.
4.6. Local Repair 4.6. Local-Repair
To support local-repair with ECMP and IPFRR LFA, access LSR/ABR To support local-repair with ECMP and IPFRR LFA, the access LSR/ABR
requests labels on both the best next-hop and the alternate next-hop requests labels on both the best next-hop and the alternate next-hop
LDP DoD sessions, as specified in the Label Request procedures in LDP DoD sessions, as specified in the Label Request procedures in
Section 4.3. If remote LFA is enabled, access LSR/ABR needs a label Section 4.3. If remote LFA is enabled, the access LSR/ABR needs a
from its alternate next-hop toward the PQ node and needs a label from label from its alternate next hop toward the PQ node and needs a
the remote PQ node toward its FEC/destination. If access LSR/ABR label from the remote PQ node toward its FEC/destination [RLFA]. If
doesn't already know those labels, it requests them. the access LSR/ABR doesn't already know those labels, it requests
them.
This will enable access LSR/ABR to pre-program the alternate This will enable the access LSR/ABR to pre-program the alternate
forwarding path with the alternate label(s), and invoke IPFRR LFA forwarding path with the alternate label(s) and invoke the IPFRR LFA
switch-over procedure if the primary next-hop link fails. switchover procedure if the primary next-hop link fails.
5. LDP Extension for LDP DoD Fast-Up Convergence 5. LDP Extension for LDP DoD Fast-Up Convergence
In some conditions, the exponential backoff algorithm usage described In some conditions, the exponential backoff algorithm usage described
in Section 4.3.2 can result in a longer than desired wait time to get in Section 4.3.2 can result in a wait time that is longer than
a successful LDP label to route mapping. An example is when a desired to get a successful LDP label-to-route mapping. An example
specific route is unavailable on the downstream LSR when the Label is when a specific route is unavailable on the downstream LSR when
Mapping request from the upstream is received, but later comes back. the label mapping request from the upstream is received, but later
In such case using the exponential backoff algorithm can result in a comes back. In such a case, using the exponential backoff algorithm
max delay wait time before the upstream LSR sends another LDP Label can result in a max delay wait time before the upstream LSR sends
Request. another LDP Label Request.
This section describes an extension to the LDP DoD procedure to This section describes an extension to the LDP DoD procedure to
address fast-up convergence, and as such is to be treated as a address fast-up convergence, and as such is to be treated as a
normative reference. The downstream and upstream LSRs SHOULD normative reference. The downstream and upstream LSRs SHOULD
implement this extension if the improvement in up convergence is implement this extension if fast-up convergence is desired.
desired.
The extension consists of the upstream LSR indicating to the The extension consists of the upstream LSR indicating to the
downstream LSR that the Label Request SHOULD be queued on the downstream LSR that the Label Request SHOULD be queued on the
downstream LSR until the requested route is available. downstream LSR until the requested route is available.
To implement this behavior, a new Optional Parameter is defined for To implement this behavior, a new Optional Parameter is defined for
use in the Label Request message: use in the Label Request message:
Optional Parameter Length Value Optional Parameter Length Value
Queue Request TLV 0 see below Queue Request TLV 0 see below
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Queue Request (0x0971) | Length (0x00) | |1|0| Queue Request (0x0971) | Length (0x00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit = 1 U-bit = 1
Unknown TLV bit. Upon receipt of an unknown TLV, due to U-bit Unknown TLV bit. Upon receipt of an unknown TLV, due to the
being set (=1), the unknown TLV MUST be silently ignored and the U-bit being set (=1), the unknown TLV MUST be silently ignored
rest of the message processed as if the unknown TLV did not and the rest of the message processed as if the unknown TLV
exist. In case requested route is not available, the downstream did not exist. In case the requested route is not available,
LSR MUST ignore this unknown TLV and send a "no route" the downstream LSR MUST ignore this unknown TLV and send a
notification back. Ensures backward compatibility. "No Route" notification back. This ensures backward
compatibility.
F-bit = 0 F-bit = 0
Forward unknown TLV bit. This bit applies only when the U-bit is Forward unknown TLV bit. This bit applies only when the U-bit is
set and the LDP message containing the unknown TLV is to be set and the LDP message containing the unknown TLV is to be
forwarded. Due to F-bit being clear (=0), the unknown TLV is not forwarded. Due to the F-bit being clear (=0), the unknown TLV is
forwarded with the containing message. not forwarded with the message.
Type Type = 0x0971
Queue Request Type value to be allocated by IANA. Queue Request TLV (allocated by IANA).
Length = 0x00 Length = 0x00
Specifies the length of the Value field in octets. Specifies the length of the Value field in octets.
Specified operation is as follows. The specified operation is as follows.
To benefit from the fast-up convergence improvement, the upstream LSR To benefit from the fast-up convergence improvement, the upstream LSR
sends a Label Request message with a Queue Request TLV. sends a Label Request message with a Queue Request TLV.
If the downstream LSR supports the Queue Request TLV, it verifies if If the downstream LSR supports the Queue Request TLV, it verifies if
route is available and if so it replies with Label Mapping as per a route is available; if so, it replies with a label mapping as per
existing LDP procedures. If the route is not available, the existing LDP procedures. If the route is not available, the
downstream LSR queues the request and replies as soon as the route downstream LSR queues the request and replies as soon as the route
becomes available. In the meantime, it does not send a "no route" becomes available. In the meantime, it does not send a "No Route"
notification back. When sending a Label Request with the Queue notification back. When sending a Label Request with the Queue
Request TLV, the upstream LSR does not retry the Label Request Request TLV, the upstream LSR does not retry the Label Request
message if it does not receive a reply from its downstream peer message if it does not receive a reply from its downstream peer.
If the upstream LSR wants to abort an outstanding Label Request while If the upstream LSR wants to abort an outstanding Label Request while
the Label Request is queued in the downstream LSR, the upstream LSR the Label Request is queued in the downstream LSR, the upstream LSR
sends a Label Abort Request message, making the downstream LSR to sends a Label Abort Request message, making the downstream LSR remove
remove the original request from the queue and send back a the original request from the queue and send back a Label Request
notification Label Request Aborted [RFC5036]. Aborted notification [RFC5036].
If the downstream LSR does not support the Queue Request TLV, and If the downstream LSR does not support the Queue Request TLV, and the
requested route is not available, it ignores this unknown TLV and requested route is not available, it ignores this unknown TLV and
sends a "no route" notification back in line with [RFC5036]. In this sends a "No Route" notification back, in line with [RFC5036]. In
case the upstream LSR invokes the exponential backoff algorithm this case, the upstream LSR invokes the exponential backoff algorithm
described in Section 4.3.2 following standard LDP specification LDP described in Section 4.3.2, following the LDP specification
specification [RFC5036]. [RFC5036].
This described procedure ensures backward compatitibility. This procedure ensures backward compatibility.
6. IANA Considerations 6. IANA Considerations
6.1. LDP TLV TYPE 6.1. LDP TLV Type
This document uses a new a new Optional Parameter Queue Request TLV This document uses a new Optional Parameter, Queue Request TLV, in
in the Label Request message defined in Section 5. IANA already the Label Request message defined in Section 5. IANA already
maintains a registry of name LDP "TLV TYPE NAME SPACE" defined by maintains a registry of LDP parameters called the "TLV Type Name
RFC5036. The following value is suggested for assignment: Space" registry, as defined by RFC 5036. The following assignment
has been made:
TLV type Description TLV type Description
0x0971 Queue Request TLV 0x0971 Queue Request TLV
7. Security Considerations 7. Security Considerations
MPLS LDP Downstream on Demand deployment in the access network is
subject to similar security threats as any MPLS LDP deployment. It MPLS LDP DoD deployment in the access network is subject to the same
is recommended that baseline security measures are considered as security threats as any MPLS LDP deployment. It is recommended that
described in Security Framework for MPLS and GMPLS networks [RFC5920] baseline security measures be considered, as described in "Security
and the LDP specification [RFC5036] including ensuring authenticity Framework for MPLS and GMPLS Networks" [RFC5920] and the LDP
and integrity of LDP messages, as well as protection against spoofing specification [RFC5036] including ensuring authenticity and integrity
and Denial of Service attacks. of LDP messages, as well as protection against spoofing and denial-
of-service attacks.
Some deployments require increased measures of network security if a Some deployments require increased measures of network security if a
subset of Access Nodes are placed in locations with lower levels of subset of access nodes are placed in locations with lower levels of
physical security e.g. street cabinets (common practice for VDSL physical security, e.g., street cabinets (common practice for Very
access). In such cases it is the responsibility of the system high bit-rate Digital Subscriber Line (VDSL) access). In such cases,
designer to take into account the physical security measures it is the responsibility of the system designer to take into account
(environmental design, mechanical or electronic access control, the physical security measures (environmental design, mechanical or
intrusion detection), as well as monitoring and auditing measures electronic access control, intrusion detection) as well as monitoring
(configuration and Operating System changes, reloads, routes and auditing measures (configuration and Operating System changes,
advertisements). reloads, route advertisements).
But even with all this in mind, the designer still needs to consider But even with all this in mind, the designer still needs to consider
network security risks and adequate measures arising from the lower network security risks and adequate measures arising from the lower
level of physical security of those locations. level of physical security of those locations.
7.1. LDP DoD Native Security Properties 7.1. LDP DoD Native Security Properties
MPLS LDP Downstream on Demand operation is request driven and MPLS LDP DoD operation is request driven, and unsolicited label
unsolicited label mappings are not accepted by upstream LSR by mappings are not accepted by upstream LSRs by design. This
design. This inherently limits the potential of an unauthorized inherently limits the potential of an unauthorized third party
third party injecting unsolicited label mappings on the wire. injecting unsolicited label mappings on the wire.
This native security property enables ABR LSR to act as a gateway to This native security property enables an ABR LSR to act as a gateway
the MPLS network and to control the requests coming from any Access to the MPLS network and to control the requests coming from any
LSR and prevent cases when the Access LSR attempts to get access to access LSR and prevent cases when the access LSR attempts to get
an unauthorized FEC or remote LSR after being compromised. access to an unauthorized FEC or remote LSR after being compromised.
In the event when Access LSR gets compromised, and manages to In the event that an access LSR gets compromised and manages to
advertise a FEC belonging to another LSR (e.g. in order to 'steal' advertise a FEC belonging to another LSR (e.g., in order to 'steal'
third party data flows, or breach a privacy of a VPN), such Access third-party data flows, or breach the privacy of a VPN), such an
LSR would also have to influence the routing decision for affected access LSR would also have to influence the routing decision for
FEC on the ABR LSR to attract the flows. Following measures need to affected FECs on the ABR LSR to attract the flows. The following
be considered on ABR LSR to prevent such event from occurring: measures need to be considered on an ABR LSR to prevent such an event
from occurring:
a. Access with static routes - Access LSR can not influence ABR LSR a. Access with static routes: An access LSR cannot influence ABR LSR
routing decisions due to static nature of routing configuration, routing decisions due to the static nature of routing
native property of the design. configuration, a native property of the design.
b. Access with IGP - access FEC "stealing" - if the compromised b. Access with IGP - access FEC "stealing": If the compromised
Access LSR is a leaf in the access topology (leaf node in access LSR is a leaf in the access topology (leaf node in
topologies I1, I, V, Y described earlier), this will not have any topologies I1, I, V, Y described earlier), this will not have any
adverse effect, due to the leaf IGP metrics being configured on adverse effect, due to the leaf IGP metrics being configured on
the ABR LSR. If the compromised Access LSR is a transit LSR in the ABR LSR. If the compromised access LSR is a transit LSR in
the access topology (transit node in topologies I, Y, U), it is the access topology (transit node in topologies I, Y, U), it is
only possible for this Access LSR to attract traffic destined to only possible for this access LSR to attract traffic destined to
the nodes upstream from it. Such a 'man in the middle attack' the nodes upstream from it. Such a 'man-in-the-middle attack'
can be quickly detected by upstream Access LSRs not receiving can quickly be detected by upstream access LSRs not receiving
traffic and LDP TCP session being lost. traffic and by the LDP TCP session being lost.
c. Access with IGP - network FEC "stealing" - the compromised Access c. Access with IGP - network FEC "stealing": The compromised access
LSR can use IGP to advertise "stolen" FEC prefix belonging to the LSR can use IGP to advertise a "stolen" FEC prefix belonging to
network side. This case can be prevented by giving a better the network side. This case can be prevented by giving a better
administrative preference to the labeled unicast BGP routes vs. administrative preference to the BGP labeled IP routes versus
access IGP routes. access IGP routes.
In summary the native properties of MPLS in access design with LDP In summary, the native properties of MPLS in access design with LDP
DoD prevent a number of security attacks and make their detection DoD prevent a number of security attacks and make their detection
quick and straightforward. quick and straightforward.
Following two sections describe other security considerations The following two sections describe other security considerations
applicable to general MPLS deployments in the access. applicable to general MPLS deployments in the access network.
7.2. Data Plane Security 7.2. Data-Plane Security
Data plane security risks applicable to the access MPLS network Data-plane security risks applicable to the access MPLS network
include : include:
a. Labelled packets from specific Access LSR are sent to an a. Labeled packets from a specific access LSR that are sent to an
unauthorized destination. unauthorized destination.
b. Unlabelled packets are sent by Access LSR to remote network b. Unlabeled packets that are sent by an access LSR to remote
nodes. network nodes.
Following mechanisms apply to MPLS access design with LDP DoD that The following mechanisms apply to MPLS access design with LDP DoD
address listed data plane security risks: that address listed data-plane security risks:
1. addressing (a) - Access and ABR LSRs are not accepting labeled 1. addressing (a): Access and ABR LSRs do not accept labeled packets
packets over a particular data link, unless from the Access or over a particular data link, unless from the access or ABR LSR
ABR LSR perspective this data link is known to attach to a perspective this data link is known to attach to a trusted system
trusted system based on control plane security described in based on control-plane security as described in Section 7.3 and
Section 7.3, and the top label has been distributed to the the top label has been distributed to the upstream neighbor by
upstream neighbour by the receiving Access or ABR LSR. the receiving access or ABR LSR.
2. addressing (a) - ABR LSR restricts network reachability for 2. addressing (a) - The ABR LSR restricts network reachability for
access devices to a subset of remote network LSRs, based on access devices to a subset of remote network LSRs, based on
control plane security described in Section 7.3, FEC filters and control-plane security as described in Section 7.3, FEC filters,
routing policy. and routing policy.
3. addressing (a) - use control plane authentication described in 3. addressing (a): Control-plane authentication as described in
Section 7.3. Section 7.3 is used.
4. addressing (b) - ABR LSR restricts IP network reachability to and 4. addressing (b): The ABR LSR restricts IP network reachability to
from the Access LSR. and from the access LSR.
7.3. Control Plane Security 7.3. Control-Plane Security
Similarly to Inter-AS MPLS/VPN deployments [RFC4364], the control Similar to Inter-AS MPLS/VPN deployments [RFC4364], control-plane
plane security is prerequisite to the data plane security. security is a prerequisite for data-plane security.
To ensure control plane security access LDP DoD sessions are To ensure control-plane security access, LDP DoD sessions are
established only with LDP peers that are considered trusted from the established only with LDP peers that are considered trusted from the
local LSR perspective, meaning they are reachable over a data link local LSR perspective, meaning they are reachable over a data link
that is known to attach to a trusted system based on employed that is known to attach to a trusted system based on employed
authentication mechanism(s) on the local LSR. authentication mechanism(s) on the local LSR.
The security of LDP sesions is analyzed in LDP specification The security of LDP sessions is analyzed in the LDP specification
[RFC5036] and in Analysis of BGP, LDP, PCEP and MSDP Issues According [RFC5036] and in [RFC6952] ("Analysis of BGP, LDP, PCEP, and MSDP
to KARP Design Guide [I-D.ietf-karp-routing-tcp-analysis]. Both Issues According to the Keying and Authentication for Routing
documents state that LDP is subject to two different types of attacks Protocols (KARP) Design Guide"). Both documents state that LDP is
- spoofing and denial of service attacks. subject to two different types of attacks: spoofing and denial-of-
service attacks.
Threat of spoofed LDP Hello messages can be reduced by following The threat of spoofed LDP Hello messages can be reduced by following
guidelines listed in LDP specification [RFC5036]: accepting Basic guidelines listed in the LDP specification [RFC5036]: accepting Basic
Hellos only on interfaces connected to trusted LSRs, ignoring Basic Hellos only on interfaces connected to trusted LSRs, ignoring Basic
Hellos that are not addressed to All Routers on this Subnet multicast Hellos that are not addressed to all routers in this subnet multicast
group, using access lists. LDP Hello messages can be also secured group, and using access lists. LDP Hello messages can also be
using an optional Cryptographic Authentication TLV specified in LDP secured using an optional Cryptographic Authentication TLV as
Hello Cryptographic Authentication specified in "LDP Hello Cryptographic Authentication" [CRYPTO-AUTH]
[I-D.ietf-mpls-ldp-hello-crypto-auth], what further reduces the that further reduces the threat of spoofing during the LDP discovery
threat of spoofing during LDP discovery phase. phase.
Spoofing during LDP session communication phase can be prevented by Spoofing during the LDP session communication phase can be prevented
using TCP Authentication Option TCP-AO [RFC5925] that uses a stronger by using the TCP Authentication Option (TCP-AO) [RFC5925], which uses
hashing algorithm e.g. SHA1 compared to traditionally used MD5 a stronger hashing algorithm, e.g., SHA1 as compared to the
authentication. TCP-AO is recommended as more secure compared to TCP traditionally used MD5 authentication. TCP-AO is recommended as
/IP MD5 authentication option [RFC5925]. being more secure as compared to the TCP/IP MD5 authentication option
[RFC5925].
The threat of the Denial of Service targetting well-known UDP port The threat of a denial-of-service attack targeting a well-known UDP
for LDP discovery and TCP port for LDP session establishment can be port for LDP discovery or a TCP port for LDP session establishment
reduced by following the guidelines listed in [RFC5036] and in can be reduced by following the guidelines listed in [RFC5036] and in
[I-D.ietf-karp-routing-tcp-analysis]. [RFC6952].
Access IGP (if used) and any routing protocols used in access network Access IGP (if used) and any routing protocols used in the access
for signaling service routes needs also to be secured following network for signaling service routes also need to be secured
routing protocol security best practices. Refer to KARP IS-IS following best practices in routing protocol security. Refer to the
security analysis [I-D.ietf-karp-isis-analysis] and Analysis of OSPF KARP IS-IS security analysis document [KARP-ISIS] and to [RFC6863]
Security According to KARP Design Guide [RFC6863] for further ("Analysis of OSPF Security According to the Keying and
analysis of security properties of IS-IS and OSPF IGP routing Authentication for Routing Protocols (KARP) Design Guide") for
further analysis of security properties of IS-IS and OSPF IGP routing
protocols. protocols.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai
Leymann, George Swallow, Geraldine Calvignac, Ina Minei, Eric Gray Leymann, George Swallow, Geraldine Calvignac, Ina Minei, Eric Gray,
and Lizhong Jin for their suggestions and review. Additional thanks and Lizhong Jin for their suggestions and review. Additional thanks
go to Adrian Farrel for thorough pre-publication review, Stephen Kent go to Adrian Farrel for thorough pre-publication review, and to
for review and guidance specifically for the security section. Stephen Kent for review and guidance specifically for the security
section.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
skipping to change at page 30, line 42 skipping to change at page 33, line 31
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
for Inter-Area Label Switched Paths (LSPs)", RFC 5283, for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
July 2008. July 2008.
9.2. Informative References 9.2. Informative References
[I-D.ietf-karp-isis-analysis] [CRYPTO-AUTH]
Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security
analysis", draft-ietf-karp-isis-analysis-00 (work in
progress), March 2013.
[I-D.ietf-karp-routing-tcp-analysis]
Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP and MSDP Issues According to KARP Design
Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in
progress), April 2013.
[I-D.ietf-mpls-ldp-hello-crypto-auth]
Zheng, L., Chen, M., and M. Bhatia, "LDP Hello Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
Cryptographic Authentication", draft-ietf-mpls-ldp-hello- Cryptographic Authentication", Work in Progress, August
crypto-auth-01 (work in progress), January 2013. 2013.
[I-D.ietf-mpls-seamless-mpls] [KARP-ISIS]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security
M., and D. Steinberg, "Seamless MPLS Architecture", draft- analysis", Work in Progress, March 2013.
ietf-mpls-seamless-mpls-03 (work in progress), May 2013.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, March 2009. Synchronization", RFC 5443, March 2009.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863, March 2013. Protocols (KARP) Design Guide", RFC 6863, March 2013.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.
[RLFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote LFA FRR", Work in Progress, May 2013.
[SEAMLESS-MPLS]
Leymann, N., Ed., Decraene, B., Filsfils, C.,
Konstantynowicz, M., Ed., and D. Steinberg, "Seamless MPLS
Architecture", Work in Progress, July 2013.
Authors' Addresses Authors' Addresses
Thomas Beckhaus (editor) Thomas Beckhaus (editor)
Deutsche Telekom AG Deutsche Telekom AG
Heinrich-Hertz-Strasse 3-7 Heinrich-Hertz-Strasse 3-7
Darmstadt 64307 Darmstadt 64307
Germany Germany
Phone: +49 6151 58 12825 Phone: +49 6151 58 12825
Email: thomas.beckhaus@telekom.de EMail: thomas.beckhaus@telekom.de
Bruno Decraene Bruno Decraene
Orange Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy Moulineaux cedex 9 92794 Issy Moulineaux cedex 9 92794
France France
Email: bruno.decraene@orange.com EMail: bruno.decraene@orange.com
Kishore Tiruveedhula Kishore Tiruveedhula
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
USA USA
Phone: 1-(978)-589-8861 Phone: 1-(978)-589-8861
Email: kishoret@juniper.net EMail: kishoret@juniper.net
Maciek Konstantynowicz (editor) Maciek Konstantynowicz (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
10 New Square Park, Bedfont Lakes 10 New Square Park, Bedfont Lakes
London London
United Kingdom United Kingdom
Email: maciek@cisco.com EMail: maciek@cisco.com
Luca Martini Luca Martini
Cisco Systems, Inc. Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400 9155 East Nichols Avenue, Suite 400
Englewood, CO 80112 Englewood, CO 80112
USA USA
Email: lmartini@cisco.com EMail: lmartini@cisco.com
 End of changes. 257 change blocks. 
827 lines changed or deleted 832 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/