One document matched: draft-ietf-mpls-ldp-dod-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.mpls-seamless-mpls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-seamless-mpls.xml">
<!ENTITY I-D.ietf-mpls-ldp-ipv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-ldp-ipv6.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mpls-ldp-dod-06" ipr="trust200902">
<front>
<title abbrev="LDP DoD">LDP Downstream-on-Demand in Seamless MPLS</title>
<author fullname="Thomas Beckhaus" initials="T" surname="Beckhaus">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>Heinrich-Hertz-Strasse 3-7</street>
<city>Darmstadt</city>
<code>64307</code>
<country>Germany</country>
</postal>
<phone>+49 6151 58 12825</phone>
<email>thomas.beckhaus@telekom.de</email>
</address>
</author>
<author fullname="Bruno Decraene" initials="B" surname="Decraene">
<organization>France Telecom</organization>
<address>
<postal>
<street>38-40 rue du General Leclerc</street>
<city>Issy Moulineaux cedex 9</city>
<code>92794</code>
<country>France</country>
</postal>
<email>bruno.decraene@orange.com</email>
</address>
</author>
<author fullname="Kishore Tiruveedhula" initials="K"
surname="Tiruveedhula">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>Massachusetts</region>
<code>01886</code>
<country>USA</country>
</postal>
<phone>1-(978)-589-8861</phone>
<email>kishoret@juniper.net</email>
</address>
</author>
<author fullname="Maciek Konstantynowicz" initials="M"
surname="Konstantynowicz">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>10 New Square Park, Bedfont Lakes</street>
<city>London</city>
<country>United Kingdom</country>
</postal>
<email>maciek@cisco.com</email>
</address>
</author>
<author fullname="Luca Martini" initials="L" surname="Martini">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>9155 East Nichols Avenue, Suite 400</street>
<city>Englewood</city>
<region>CO</region>
<code>80112</code>
<country>USA</country>
</postal>
<email>lmartini@cisco.com</email>
</address>
</author>
<date day="10" month="May" year="2013"/>
<abstract>
<t>Seamless MPLS design enables a single IP/MPLS network to scale over
core, metro and access parts of a large packet network infrastructure
using standardized IP/MPLS protocols. One of the key goals of Seamless
MPLS is to meet requirements specific to access, including high number
of devices, their position in network topology and their compute and
memory constraints that limit the amount of state access devices can
hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label
advertisement. This document describes LDP DoD use cases and lists
required LDP DoD procedures in the context of Seamless MPLS design.</t>
<t>In addition, a new optional TLV type in the LDP Label Request message
is defined for fast-up convergence.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t><xref target="I-D.ietf-mpls-seamless-mpls">Seamless MPLS
design</xref> enables a single IP/MPLS network to scale over core, metro
and access parts of a large packet network infrastructure using
standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is
to meet requirements specific to access, including high number of
devices, their position in network topology and their compute and memory
constraints that limit the amount of state access devices can hold.</t>
<t>In general MPLS Label Switching Routers implement either LDP or RSVP
for MPLS label distribution.</t>
<t>The focus of this document is on LDP, as Seamless MPLS design does
not include a requirement for general purpose explicit traffic
engineering and bandwidth reservation. Document concentrates on the
unicast connectivity only. Multicast connectivity is subject for further
study.</t>
<t>In <xref target="I-D.ietf-mpls-seamless-mpls">Seamless MPLS design
</xref>, IP/MPLS protocol optimization is possible due to a relatively
simple access network topologies. Examples of such topologies involving
access nodes (AN) and aggregation nodes (AGN) include:</t>
<t><list style="letters">
<t hangText="">A single AN homed to a single AGN.</t>
<t>A single AN dual-homed to two AGNs.</t>
<t>Multiple ANs daisy-chained via a hub-AN to a single AGN.</t>
<t>Multiple ANs daisy-chained via a hub-AN to two AGNs.</t>
<t>Two ANs dual-homed to two AGNs.</t>
<t>Multiple ANs chained in a ring and dual-homed to two AGNs.</t>
</list></t>
<t>The amount of IP RIB and 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 of
the above topologies AGNs act as the access border routers (access ABRs)
connecting the access topology to the rest of the network. Hence in many
cases it is sufficient for ANs to have a default route pointing towards
AGNs in order to achieve complete network connectivity from ANs to the
network.</t>
<t>The amount of MPLS forwarding state however requires additional
consideration. In general MPLS routers implement LDP Downstream
Unsolicited (LDP DU) label advertisement <xref target="RFC5036"/> and
advertise MPLS labels for all valid routes in their RIB. This is seen as
an inadequate approach for ANs, which requires a small subset of the
total routes (and associated labels) based on the required connectivity
for the provisioned services. And although filters can be applied to
those LDP DU labels advertisements, it is not seen as a suitable tool to
facilitate any-to-any AN-driven connectivity between access and the rest
of the MPLS network.</t>
<t>This document describes an access node driven "subscription model"
for label distribution in the access. The approach relies on the
standard LDP Downstream-on-Demand (LDP DoD) label advertisements as
specified in <xref target="RFC5036"/>. LDP DoD enables on-demand label
distribution ensuring that only required labels are requested, provided
and installed. Procedures described in this document are equally
applicable to LDP IPv4 and IPv6 address families. For simplicity the
document provides examples based on LDP IPv4 address family.</t>
<t>The following sections describe a set of reference access topologies
considered for LDP DoD usage and their associated IP routing
configurations, followed by LDP DoD use cases and LDP DoD procedures in
the context of Seamless MPLS design.</t>
</section>
<section anchor="sec_reference_topologies" title="Reference Topologies">
<t>LDP DoD use cases are described in the context of a generic reference
end-to-end network topology based on <xref
target="I-D.ietf-mpls-seamless-mpls">Seamless MPLS design </xref> shown
in <xref target="fig_seamless_mpls_e2e_ref_network_topology"/></t>
<t><figure align="center"
anchor="fig_seamless_mpls_e2e_ref_network_topology"
title="Seamless MPLS end-to-end reference network topology.">
<artwork><![CDATA[ +-------+ +-------+ +------+ +------+
---+ AGN11 +--+ AGN21 +--+ ABR1 +--+ LSR1 +--> to LSR/AGN
+--------+/ +-------+ +-------+ +------+ +------+
| Access | \/ \/
| Network| /\ /\
+--------+ +-------+ +-------+ +------+ +------+
\---+ AGN12 +--+ AGN22 +--+ ABR2 +--+ LSR2 +--> to LSR/AGN
+-------+ +-------+ +------+ +------+
static routes
or access IGP IGP area IGP area
<----Access----><--Aggregation Domain--><----Core----->
<------------------------- MPLS ---------------------->
]]></artwork>
<postamble/>
</figure></t>
<t>The access network is either single or dual homed to AGN1x, with
either a single or multiple parallel links to AGN1x.</t>
<t>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
either static routing or access IGP ( ISIS or OSPF ). The following
sections describe reference access topologies in more detail.</t>
<section title="Access Topologies with Static Routing">
<t>In most cases access nodes connect to the rest of the network using
very simple topologies. Here static routing is sufficient to provide
the required IP connectivity. The following topologies are considered
for use with static routing and LDP DoD:</t>
<t><list style="letters">
<t>[I1] topology - a single AN homed to a single AGN.</t>
<t>[I] topology - multiple ANs daisy-chained to a single AGN.</t>
<t>[V] topology - a single AN dual-homed to two AGNs.</t>
<t>[U2] topology - two ANs dual-homed to two AGNs.</t>
<t>[Y] topology - multiple ANs daisy-chained to two AGNs.</t>
</list></t>
<t>The reference static routing and LDP configuration for [V] access
topology is shown in <xref
target="fig_v_access_topology_with_static_routes"/>. The same static
routing and LDP configuration also applies to [I1] topology.</t>
<t><figure align="center"
anchor="fig_v_access_topology_with_static_routes"
title="[V] access topology with static routes.">
<artwork><![CDATA[ +----+ +-------+
|AN1 +------------------------+ AGN11 +-------
| +-------\ /-----------+ +-\ /
+----+ \ / +-------+ \ /
\/ \/
/\ /\
+----+ / \ +-------+ / \
|AN2 +-------/ \-----------+ AGN12 +-/ \
| +------------------------+ +-------
+----+ +-------+
--(u)-> <-(d)--
<----- static routing -------> <--- IGP ---->
<-- LDP DU -->
<--------- LDP DoD ----------> <-- BGP LU -->
(u) static routes: 0/0 default, (optional) /32 routes
(d) static routes: AN loopbacks
]]></artwork>
<postamble/>
</figure></t>
<t>In line with the Seamless MPLS design, static routes configured on
AGN1x and pointing towards the access network are redistributed in
either IGP or <xref target="RFC3107">BGP labeled unicast
(BGP-LU)</xref>.</t>
<t>The reference static routing and LDP configuration for [U2] access
topology is shown in <xref
target="fig_u2_access_topology_with_static_routes"/>.</t>
<t><figure align="center"
anchor="fig_u2_access_topology_with_static_routes"
title="[U2] access topology with static routes.">
<artwork><![CDATA[ +----+ +-------+
(d1) |AN1 +------------------------+ AGN11 +-------
| | + + +-\ /
v +-+--+ +-------+ \ /
| \/
| /\
^ +-+--+ +-------+ / \
| |AN2 + + AGN12 +-/ \
(d2) | +------------------------+ +-------
+----+ +-------+
--(u)-> <-(d)--
<------- static routing --------> <--- IGP ---->
<-- LDP DU -->
<----------- LDP DoD -----------> <-- BGP LU -->
(u) static route 0/0 default, (optional) /32 routes
(d) static route for AN loopbacks
(d1) static route for AN2 loopback and 0/0 default with
lower preference
(d2) static route for AN1 loopback and 0/0 default with
lower preference
]]></artwork>
<postamble/>
</figure></t>
<t>The reference static routing and LDP configuration for [Y] access
topology is shown in <xref
target="fig_y_access_topology_with_static_routes"/>. The same static
routing and LDP configuration also applies to [I] topology.</t>
<t><figure align="center"
anchor="fig_y_access_topology_with_static_routes"
title="[Y] access topology with static routes.">
<artwork><![CDATA[ +-------+
| |---/
/----+ AGN11 |
+----+ +----+ +----+ / | |---\
| | | | | +----/ +-------+
|ANn +...|AN2 +---+AN1 |
| | | | | +----\ +-------+
+----+ +----+ +----+ \ | |---/
\----+ AGN12 |
<-(d2)-- <-(d1)-- | |---\
--(u)-> --(u)-> --(u)-> +-------+
<-(d)--
<------- static routing -------> <--- IGP ---->
<-- LDP DU -->
<---------- LDP DoD -----------> <-- BGP LU -->
(u) static routes: 0/0 default, (optional) /32 routes
(d) static routes: AN loopbacks [1..n]
(d1) static routes: AN loopbacks [2..n]
(d2) static routes: AN loopbacks [3..n]
]]></artwork>
<postamble/>
</figure></t>
<t>Note that in all of the above topologies parallel ECMP (or L2 LAG)
links can be used between the nodes.</t>
<t>ANs support <xref target="RFC5283">Inter-area LDP</xref> in order
to use the IP default route to match the LDP FEC advertised by AGN1x
and other ANs.</t>
</section>
<section title="Access Topologies with Access IGP">
<t>A dedicated access IGP instance is used in the access network to
perform the internal routing between AGN1x and connected AN devices.
Example of such IGP could be ISIS, OSPFv2&v3, RIPv2&RIPng.
This access IGP instance is distinct from the IGP of the aggegation
domain.</t>
<t>The following topologies are considered for use with access IGP
routing and LDP DoD:</t>
<t><list style="letters">
<t>[U] topology - multiple ANs chained in an open ring and
dual-homed to two AGNs.</t>
<t>[Y] topology - multiple ANs daisy-chained via a hub-AN to two
AGNs.</t>
</list></t>
<t>The reference access IGP and LDP configuration for [U] access
topology is shown in <xref
target="fig_u_access_topology_with_access_igp"/>.</t>
<t><figure align="center"
anchor="fig_u_access_topology_with_access_igp"
title="[U] access topology with access IGP.">
<artwork><![CDATA[ +-------+
+-----+ +-----+ +----+ | +---/
| AN3 |---| AN2 |---|AN1 +-----+ AGN11 |
+-----+ +-----+ +----+ | +---\
. +-------+
.
. +-------+
+-----+ +-----+ +----+ | +---/
|ANn-2|---|ANn-1|---|ANn +-----+ AGN12 |
+-----+ +-----+ +----+ | +---\
+-------+
<---------- access IGP ------------> <--- IGP ---->
<-- LDP DU -->
<------------ LDP DoD -------------> <-- BGP LU -->
]]></artwork>
<postamble/>
</figure></t>
<t>The reference access IGP and LDP configuration for [Y] access
topology is shown in <xref
target="fig_y_access_topology_with_access_igp"/>.</t>
<t><figure align="center"
anchor="fig_y_access_topology_with_access_igp"
title="[Y] access topology with access IGP.">
<artwork><![CDATA[ +-------+
| |---/
/----+ AGN11 |2
+----+ +----+ +----+ / | |---\
| | | | | +----/ +-------+
|ANn +...|AN2 +---+AN1 |
| | | | | +----\ +-------+
+----+ +----+ +----+ \ | |---/
\----+ AGN12 |
| |---\
+-------+
<---------- access IGP ------------> <--- IGP ---->
<-- LDP DU -->
<------------ LDP DoD -------------> <-- BGP LU -->
]]></artwork>
<postamble/>
</figure></t>
<t>Note that in all of the above topologies parallel ECMP (or L2 LAG)
links can be used between the nodes.</t>
<t>In both of the above topologies, ANs (ANn ... AN1) and AGN1x share
the access IGP and advertise their IPv4 and IPv6 loopbacks and link
addresses. AGN1x advertise a default route into the access IGP.</t>
<t>ANs support <xref target="RFC5283">Inter-area LDP</xref> in order
to use the IP default route for matching the LDP FECs advertised by
AGN1x or other ANs.</t>
</section>
</section>
<section anchor="sec_ldp_dod_use_cases" title="LDP DoD Use Cases">
<t>LDP DoD use cases described in this document are based on the
Seamless MPLS scenarios listed in <xref
target="I-D.ietf-mpls-seamless-mpls">Seamless MPLS design</xref>. This
section illustrates these use cases focusing on services provisioned on
the access nodes and clarifies expected LDP DoD operation on the AN and
AGN1x devices. Two representative service types are used to illustrate
the service use cases: MPLS PWE3 <xref target="RFC4447"/> and BGP/MPLS
IPVPN <xref target="RFC4364"/>.</t>
<t>Described LDP DoD operations apply equally to all reference access
topologies described in <xref target="sec_reference_topologies"/>.
Operations that are specific to certain access topologies are called out
explicitly.</t>
<t>References to upstream and downstream nodes are made in line with the
definition of upstream and downstream LSR <xref target="RFC3031"/>.</t>
<t>LDP DoD procedures follow the LDP specification <xref
target="RFC5036"/>, and are equally applicable to LDP IPv4 and IPv6
address families. For simplicity examples are provided for LDP IPv4
address family only.</t>
<section anchor="sec_initial_network_setup"
title="Initial Network Setup">
<t>An access node is commissioned without any services provisioned on
it. The AN may request labels for loopback addresses of any AN, AGN or
other nodes within Seamless MPLS network for operational and
management purposes. It is assumed that AGN1x has required IP/MPLS
configuration for network-side connectivity in line with <xref
target="I-D.ietf-mpls-seamless-mpls">Seamless MPLS design</xref>.</t>
<t>LDP sessions are configured between adjacent ANs and AGN1x using
their respective loopback addresses.</t>
<section title="AN with Static Routing">
<t>If access static routing is used, ANs are provisioned with the
following static IP routing entries (topology references from <xref
target="sec_reference_topologies"/> are listed in square
brackets):</t>
<t><list style="letters">
<t>[I1, V, U2] - Static default route 0/0 pointing to links
connected to AGN1x. Requires support for <xref
target="RFC5283">Inter-area LDP</xref>.</t>
<t>[U2] - Static /32 routes pointing to the other AN. Lower
preference static default route 0/0 pointing to links connected
to the other AN. Requires support for <xref
target="RFC5283">Inter-area LDP</xref>.</t>
<t>[I, Y] - Static default route 0/0 pointing to links leading
towards AGN1x. Requires support for <xref
target="RFC5283">Inter-area LDP</xref>.</t>
<t>[I, Y] - Static /32 routes to all ANs in the daisy-chain
pointing to links towards those ANs.</t>
<t>[I1, V, U2] - Optional - Static /32 routes for specific nodes
within Seamless MPLS network, pointing to links connected to
AGN1x.</t>
<t>[I, Y] - Optional - Static /32 routes for specific nodes
within the Seamless MPLS network, pointing to links leading
towards AGN1x.</t>
</list></t>
<t>Upstream AN/AGN1x should request labels over LDP DoD session(s)
from downstream AN/AGN1x for configured static routes if those
static routes are configured with LDP DoD request policy and if they
are 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 with such policy on AN/AGN1x.</t>
<t>Downstream AN/AGN1x should respond to the Label Request from the
upstream AN/AGN1x with a Label Mapping if requested route is present
in its RIB, and there is a valid label binding from its downstream
or it is the egress node. In such case downstream AN/AGN1x must
install the advertised label as an incoming label in its label table
(LIB) and its forwarding table (LFIB). Upstream AN/AGN1x must also
install the received label as an outgoing label in their LIB and
LFIB. If the downstream AN/AGN1x does have the route present in its
RIB, but does not have a valid label binding from its downstream, it
should forward the request to its downstream.</t>
<t>In order to facilitate ECMP and IPFRR LFA local-repair, the
upstream AN/AGN1x must also send LDP DoD label requests to alternate
next-hops per its RIB, and install received labels as alternate
entries in its LIB and LFIB.</t>
<t>AGN1x node on the network side may use <xref target="RFC3107">BGP
labeled unicast</xref> in line with <xref
target="I-D.ietf-mpls-seamless-mpls">the Seamless MPLS
design</xref>. In such a case AGN1x will be redistributing its
static routes pointing to local ANs into BGP labeled unicast to
facilitate network-to-access traffic flows. Likewise, to facilitate
access-to-network traffic flows, AGN1x will be responding to
access-originated LDP DoD label requests with label mappings based
on its BGP labeled unicast reachability for requested FECs.</t>
</section>
<section anchor="sec_an_with_access_igp" title="AN with Access IGP">
<t>If access IGP is used, AN(s) advertise their loopbacks over the
access IGP with configured metrics. AGN1x advertise a default route
over the access IGP.</t>
<t>Routers request labels over LDP DoD session(s) according to their
needs for MPLS connectivity (LSPs). In particular if AGNs, as per
<xref target="I-D.ietf-mpls-seamless-mpls">Seamless MPLS
design</xref>, redistribute routes from the IGP into <xref
target="RFC3107">BGP labeled unicast</xref>, they should request
labels over LDP DoD session(s) for those routes.</t>
<t>Identically to the static route case, downstream AN/AGN1x should
respond to the Label Request from the upstream AN/AGN1x with a Label
Mapping (if the requested route is present in its RIB, and there is
a valid label binding from its downstream), and must install the
advertised label as an incoming label in its LIB and LFIB. Upstream
AN/AGN1x must also install the received label as an outgoing label
in their LIB and LFIB.</t>
<t>Identically to the static route case, in order to facilitate ECMP
and IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD
label requests to alternate next-hops per its RIB, and install
received labels as alternate entries in its LIB and LFIB.</t>
<t>AGN1x node on the network side may use <xref target="RFC3107">BGP
labeled unicast</xref> in line with <xref
target="I-D.ietf-mpls-seamless-mpls">Seamless MPLS design</xref>. In
such case AGN1x will be redistributing routes received over the
access IGP (and pointing to local ANs), into BGP labeled unicast to
facilitate network-to-access traffic flows. Likewise, to facilitate
access-to-network traffic flows AGN1x will be responding to access
originated LDP DoD label requests with label mappings based on its
BGP labeled unicast reachability for requested FECs.</t>
</section>
</section>
<section anchor="sec_service_provisioning_and_activation"
title="Service Provisioning and Activation">
<t>Following the initial setup phase described in <xref
target="sec_initial_network_setup"/>, a specific access node, referred
to as AN*, is provisioned with a 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 operations are service agnostic,
that is, they are the same independently of the services provisioned
on the AN*.</t>
<t>For illustration purposes two service types are described: MPLS
PWE3 <xref target="RFC4447"/> service and BGP/MPLS IPVPN <xref
target="RFC4364"/>.</t>
<t>MPLS PWE3 service - for description simplicity it is assumed that a
single segment pseudowire is signaled using targeted LDP FEC128
(0x80), and it is provisioned with the pseudowire ID and the loopback
IPv4 address of the destination node. The following IP/MPLS operations
need to be completed on the AN* to successfully establish such PWE3
service:<list style="letters">
<t>LSP labels for destination /32 FEC (outgoing label) and the
local /32 loopback (incoming label) need to be signaled using LDP
DoD.</t>
<t>Targeted LDP session over an associated TCP/IP connection needs
to be established to the PWE3 destination PE. This is triggered by
either an explicit targeted LDP session configuration on the AN*
or automatically at the time of provisioning the PWE3
instance.</t>
<t>Local and remote PWE3 labels for specific FEC128 PW ID need to
be signaled using targeted LDP and PWE3 signaling procedures <xref
target="RFC4447"/>.</t>
<t>Upon successful completion of the above operations, AN*
programs its RIB/LIB and LFIB tables, and activates the MPLS PWE3
service.</t>
</list></t>
<t>Note - only minimum operations applicable to service connectivity
have been listed. Other non IP/MPLS connectivity operations that may
be required for successful service provisioning and activation are out
of scope in this document.</t>
<t>BGP/MPLS IPVPN service - for description simplicity it is assumed
that AN* is provisioned with a unicast IPv4 IPVPN service (VPNv4 for
short) <xref target="RFC4364"/>. The following IP/MPLS operations need
to be completed on the AN* to successfully establish VPNv4
service:</t>
<t><list style="letters">
<t>BGP peering sessions with associated TCP/IP connections need to
be established with the remote destination VPNv4 PEs or Route
Reflectors.</t>
<t>Based on configured BGP policies, VPNv4 BGP NLRIs need to be
exchanged between AN* and its BGP peers.</t>
<t>Based on configured BGP policies, VPNv4 routes need to be
installed in the AN* VRF RIB and FIB, with corresponding BGP
next-hops.</t>
<t>LSP labels for destination BGP next-hop /32 FEC (outgoing
label) and the local /32 loopback (incoming label) need to be
signaled using LDP DoD.</t>
<t>Upon successful completion of above operations, AN* programs
its RIB/LIB and LFIB tables, and activates the BGP/MPLS IPVPN
service.</t>
</list></t>
<t>Note - only minimum operations applicable to service connectivity
have been listed. Other non IP/MPLS connectivity operations that may
be required for successful service provisioning are out of scope in
this document.</t>
<t>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,
selects the best next-hop(s) and associated outgoing link(s).</t>
<t>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
entry, AN* must send an LDP DoD Label Mapping request. Downstream
AN/AGN1x LSR(s) checks its RIB for presence of the requested /32 and
associated valid outgoing label binding, and if both are present,
replies with its label for this FEC and installs this label as
incoming in its LIB and LFIB. Upon receiving the Label Mapping the AN*
must accept this label based on the exact route match of advertised
FEC and route entry in its RIB or based on the longest match in line
with <xref target="RFC5283">Inter-area LDP</xref>. If the AN* accepts
the label it must install it as an outgoing label in its LIB and
LFIB.</t>
<t>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
paths, AN* must send LDP DoD label requests to both AGN1x devices and
install all received labels in its LIB and LFIB.</t>
<t>In order for AN* to implement IPFRR LFA local-repair, AN* must also
send LDP DoD label requests to alternate next-hops per its RIB, and
install received labels as alternate entries in its LIB and LFIB.</t>
<t>When forwarding PWE3 or VPNv4 packets AN* chooses the LSP label
based on the locally configured static /32 or default route, or
default route signaled via access IGP. If a route is reachable via
multiple interfaces to AGN1x nodes and the route has multiple equal
cost paths, AN* must implement Equal Cost Multi-Path (ECMP)
functionality. This involves AN* using hash-based load-balancing
mechanism and sending the PWE3 or VPNv4 packets in a flow-aware manner
with appropriate LSP labels via all equal cost links.</t>
<t>ECMP mechanism is applicable in an equal manner to parallel links
between two network elements and multiple paths towards the
destination. The traffic demand is distributed over the available
paths.</t>
<t>AGN1x node on the network side may use <xref target="RFC3107">BGP
labeled unicast</xref> in line with <xref
target="I-D.ietf-mpls-seamless-mpls">Seamless MPLS design </xref>. In
such case AGN1x will be redistributing its static routes (or routes
received from the access IGP) pointing to local ANs into BGP labeled
unicast to facilitate network-to-access traffic flows. Likewise, to
facilitate access-to-network traffic flows AGN1x will be responding to
access originated LDP DoD label requests with label mappings based on
its BGP labeled unicast reachability for requested FECs.</t>
</section>
<section anchor="sec_service_changes_and_decommissioning"
title="Service Changes and Decommissioning">
<t>Whenever AN* service gets decommissioned or changed and
connectivity to specific destination is not longer required, the
associated MPLS LSP label resources should be released on AN*.</t>
<t>MPLS PWE3 service - if the PWE3 service gets decommissioned and it
is the last PWE3 to a specific destination node, the targeted LDP
session is not longer needed and should be terminated (automatically
or by configuration). The MPLS LSP(s) to that destination is no longer
needed either.</t>
<t>BGP/MPLS IPVPN service - deletion of a specific VPNv4 (VRF)
instance, local or remote re-configuration may result in specific BGP
next-hop(s) being no longer needed. The MPLS LSP(s) to that
destination is no longer needed either.</t>
<t>In all of the above cases the following LDP DoD related operations
apply:</t>
<t><list style="symbols">
<t>If the /32 FEC label for the aforementioned destination node
was originally requested based on either tLDP session
configuration and default route or required BGP next-hop and
default route, AN* should delete the label from its LIB and LFIB,
and release it from downstream AN/AGN1x by using LDP DoD
procedures.</t>
<t>If the /32 FEC label was originally requested based on the
static /32 route configuration with LDP DoD request policy, the
label must be retained by AN*.</t>
</list></t>
<t/>
</section>
<section anchor="sec_service_failure" title="Service Failure">
<t>A service instance may stop being operational due to a local or
remote service failure event.</t>
<t>In general, unless the service failure event modifies required MPLS
connectivity, there should be no impact on the LDP DoD operation.</t>
<t>If the service failure event does modify the required MPLS
connectivity, LDP DoD operations apply as described in <xref
target="sec_service_provisioning_and_activation"/> and <xref
target="sec_service_changes_and_decommissioning"/>.</t>
</section>
<section anchor="sec_network_transport_failure"
title="Network Transport Failure">
<t>A number of different network events can impact services on AN*.
The following sections describe network event types that impact LDP
DoD operation on AN and AGN1x nodes.</t>
<section title="General Notes">
<t>If service on any of the ANs is affected by any network failure
and there is no network redundancy, the service must go into a
failure state. When the network failure is recovered from, the
service must be re-established automatically.</t>
<t>The following additional LDP-related functions should be
supported to comply with <xref
target="I-D.ietf-mpls-seamless-mpls">Seamless MPLS </xref> fast
service restoration requirements as follows:<list style="letters">
<t>Local-repair - AN and AGN1x should support local-repair for
adjacent link or node failure for access-to-network,
network-to-access and access-to-access traffic flows.
Local-repair should be implemented by using either IPFRR LDP
LFA, simple ECMP or primary/backup switchover upon failure
detection.</t>
<t>LDP session protection - LDP sessions should be configured
with LDP session protection to avoid delay upon the recovery
from link failure. LDP session protection ensures that FEC label
binding is maintained in the control plane as long as LDP
session stays up.</t>
<t>IGP-LDP synchronization - If access IGP is used, LDP sessions
between ANs, and between ANs and AGN1x, should be configured
with IGP-LDP synchronization to avoid unnecessary traffic loss
in case the access IGP converged before LDP and there is no LDP
label binding to the downstream best next-hop.</t>
</list></t>
<t/>
</section>
<section title="AN Node Failure">
<t>AN node fails and all links to adjacent nodes go down.</t>
<t>Adjacent AN/AGN1x nodes remove all routes pointing to the failed
link(s) from their RIB tables (including /32 loopback belonging to
the failed AN and any other routes reachable via the failed AN).
This in turn triggers the removal of associated outgoing /32 FEC
labels from their LIB and LFIB tables.</t>
<t>If access IGP is used, the AN node failure will be propagated via
IGP link updates across the access topology.</t>
<t>If a specific /32 FEC(s) is not reachable anymore from those
AN/AGN1x, they must also send LDP Label Withdraw to their upstream
LSRs to notify about the failure, and remove the associated incoming
label(s) from their LIB and LFIB tables. Upstream LSRs upon
receiving Label Withdraw should remove the signaled labels from
their LIB/LFIB tables, and propagate LDP Label Withdraw across their
upstream LDP DoD sessions.</t>
<t>In [U] topology there may be an alternative path to routes
previously reachable via the failed AN node. In this case adjacent
AN/AGN1x should invoke local-repair (IPFRR LFA, ECMP) and switchover
to alternate next-hop to reach those routes.</t>
<t>AGN1x gets notified about the AN failure via either access IGP
(if used) and/or cascaded LDP DoD label withdraw(s). AGN1x must
implement all relevant global-repair IP/MPLS procedures to propagate
the AN failure towards the core network. This should involve
removing associated routes (in access IGP case) and labels from its
LIB and LFIB tables, and propagating the failure on the network side
using BGP-LU and/or core IGP/LDP-DU procedures.</t>
<t>Upon AN coming back up, adjacent AN/AGN1x nodes automatically add
routes pointing to recovered links based on the configured static
routes or access IGP adjacency and link state updates. This should
be then followed by LDP DoD label signaling and subsequent binding
and installation of labels in LIB and LFIB tables.</t>
</section>
<section title="AN/AGN Link Failure">
<t>Depending on the access topology and the failed link location
different cases apply to the network operation after AN link failure
(topology references from <xref target="sec_reference_topologies"/>
in square brackets):</t>
<t><list style="letters">
<t>[all] - link failed, but at least one ECMP parallel link
remains - nodes on both sides of the failed link must stop using
the failed link immediately (local-repair), and keep using the
remaining ECMP parallel links.</t>
<t>[I1, I, Y] - link failed, and there are no ECMP or
alternative links and paths - nodes on both sides of the failed
link must remove routes pointing to the failed link immediately
from the RIB, remove associated labels from their LIB and LFIB
tabels, and must send LDP label withdraw(s) to their upstream
LSRs.</t>
<t>[U2, U, V, Y] - link failed, but at least one ECMP or
alternate path remains - AN/AGN1x node must stop using the
failed link and immediately switchover (local-repair) to the
remaining ECMP path or alternate path. AN/AGN1x must remove
affected next-hops and labels from its tables and invoke LDP
Label Withdraw as per point (a) above. If there is an AGN1x node
terminating the failed link, it must remove routes pointing to
the failed link immediately from the RIB, remove associated
labels from their LIB and LFIB tabels, and must propagate the
failure on the network side using BGP-LU and/or core IGP
procedures.</t>
</list></t>
<t>If access IGP is used AN/AGN1x link failure will be propagated
via IGP link updates across the access topology.</t>
<t>LDP DoD will also propagate the link failure by sending label
withdraws to upstream AN/AGN1x nodes, and Label Release messages
downstream AN/AGN1x nodes.</t>
</section>
<section title="AGN Node Failure">
<t>AGN1x fails and all links to adjacent access nodes go down.</t>
<t>Depending on the access topology, following cases apply to the
network operation after AGN1x node failure (topology references from
<xref target="sec_reference_topologies"/> in square brackets):</t>
<t><list style="letters">
<t>[I1, I] - ANs are isolated from the network - AN adjacent to
the failure must remove routes pointing to the failed AGN1x node
immediately from the RIB, remove associated labels from their
LIB and LFIB tabels, and must send LDP label withdraw(s) to
their upstream LSRs. If access IGP is used, an IGP link update
should be sent.</t>
<t>[U2, U, V, Y] - at least one ECMP or alternate path remains -
AN adjacent to failed AGN1x must stop using the failed link and
immediately switchover (local-repair) to the remaining ECMP path
or alternate path. AN must remove affected routes and labels
from its tables and invoke LDP Label Withdraw as per point (a)
above.</t>
</list></t>
<t>Network side procedures for handling AGN1x node failure have been
described in <xref target="I-D.ietf-mpls-seamless-mpls">Seamless
MPLS</xref>.</t>
</section>
<section title="AGN Network-side Reachability Failure">
<t>AGN1x loses network reachability to a specific destination or set
of network-side destinations.</t>
<t>In such event AGN1x must send LDP Label Withdraw messages to its
upstream ANs, withdrawing labels for all affected /32 FECs. Upon
receiving those messages ANs must remove those labels from their LIB
and LFIB tables, and use alternative LSPs instead if available as
part of global-repair. In turn ANs should also sent Label Withdraw
messages for affected /32 FECs to their upstream ANs.</t>
<t>If access IGP is used, and AGN1x gets completely isolated from
the core network, it should stop advertising the default route 0/0
into the access IGP.</t>
</section>
</section>
</section>
<section title="LDP DoD Procedures">
<t>Label Distribution Protocol is specified in <xref target="RFC5036"/>,
and all LDP Downstream-on-Demand implementations follow <xref
target="RFC5036"/> specification. This section does not update <xref
target="RFC5036"/> procedures, but illustrates LDP DoD operations in the
context of use cases identified in <xref
target="sec_ldp_dod_use_cases"/> in this document, for information
only.</t>
<t>In <xref target="RFC3031">the MPLS architecture</xref>, network
traffic flows from upstream to downstream LSR. The use cases in this
document rely on the downstream assignment of labels, where labels are
assigned by the downstream LSR and signaled to the upstream LSR as shown
in <xref target="ldp_label_assignment_direction"/>.</t>
<t><figure align="center" anchor="ldp_label_assignment_direction"
title="LDP label assignment direction">
<artwork><![CDATA[ +----------+ +------------+
| upstream | | downstream |
------+ LSR +------+ LSR +----
traffic | | | | address
source +----------+ +------------+ (/32 for IPv4)
traffic
label distribution for IPv4 FEC destination
<-------------------------
traffic flow
------------------------->
]]></artwork>
<postamble/>
</figure></t>
<section title="LDP Label Distribution Control and Retention Modes">
<t><xref target="RFC5036">LDP protocol specification</xref> defines
two modes for label distribution control, following the definitions in
<xref target="RFC3031">MPLS architecture</xref>:<list style="symbols">
<t>Independent mode – an LSR recognizes a particular FEC and
makes a decision to bind a label to the FEC independently from
distributing that label binding to its label distribution peers. A
new FEC is recognized whenever a new route becomes valid on the
LSR.</t>
<t>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 corresponding to that FEC ) and if it has
already received at least one Label Request message from an
upstream LSR.</t>
</list></t>
<t>Using independent label distribution control with LDP DoD and
access static routing would prevent the access LSRs from propagating
label binding failure along the access topology, making it impossible
for upstream LSR to be notified about the downstream failure and for
an application using the LSP to switchover to an alternate path, even
if such a path exists.</t>
<t><xref target="RFC5036">LDP protocol specification</xref> defines
two modes for label retention, following the definitions in <xref
target="RFC3031">MPLS architecture</xref>:<list style="symbols">
<t>Conservative mode - If operating in Downstream on Demand mode,
an LSR will request label mappings only from the next hop LSR
according to routing. The main advantage of the conservative mode
is that only the labels that are required for the forwarding of
data are allocated and maintained. This is particularly important
in LSRs where the label space is inherently limited, such as in an
ATM switch. A disadvantage of the conservative mode is that if
routing changes the next hop for a given destination, a new label
must be obtained from the new next hop before labeled packets can
be forwarded.</t>
<t>Liberal mode - When operating in Downstream on Demand mode with
Liberal Label retention, an LSR might choose to request label
mappings for all known prefixes from all peer LSRs. The main
advantage of the Liberal Label retention mode is that reaction to
routing changes can be quick because labels already exist. The
main disadvantage of the liberal mode is that unneeded label
mappings are distributed and maintained.</t>
</list></t>
<t>Note that the conservative label retention mode would prevent LSRs
from requesting and maintaining label mappings for any backup routes
that are not used for forwarding. This in turn would prevent the
access LSRs (AN and AGN1x nodes) from implementing any local
protection schemes that rely on using alternate next-hops in case of
the primary next-hop failure. Such schemes include IPFRR LFA if access
IGP is used, or a primary and backup static route configuration. Using
LDP DoD in combination with liberal retention mode allows the LSR to
request labels for the specific FEC from primary next-hop LSR(s) and
the alternate next-hop LSR(s) for this FEC.</t>
<t>Note that even though LDP DoD operates in a liberal retention 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
the new next-hop will get requested only after the access IGP
convergence.</t>
<t>Adhering to the overall design goals of <xref
target="I-D.ietf-mpls-seamless-mpls">Seamless MPLS</xref>,
specifically achieving a large network scale without compromising fast
service restoration, all access LSRs (AN and AGN1x nodes) use LDP DoD
advertisement mode with:</t>
<t><list style="symbols">
<t>Ordered label distribution control - enables propagation of
label binding failure within the access topology.</t>
<t>Liberal label retention - enables pre-programming of alternate
next-hops with associated FEC labels.</t>
</list></t>
<t>In <xref target="I-D.ietf-mpls-seamless-mpls">Seamless MPLS</xref>
AGN1x node acts as an access ABR connecting access and metro domains.
To enable failure propagation between those domains, access ABR
implements ordered label distribution control when redistributing
routes/FEC between the access-side (using LDP DoD and static or access
IGP) and the network-side ( using <xref target="RFC3107">BGP labeled
unicast</xref> or core IGP with LDP Downstream Unsolicited label
advertisement.</t>
</section>
<section anchor="sec_ldp_dod_session_negotiation"
title="LDP DoD Session Negotiation">
<t>Access LSR/ABR should propose the Downstream-on-Demand label
advertisement by setting "A" value to 1 in the Common Session
Parameters TLV of the Initialization message. The rules for
negotiating the label advertisement mode are specified in <xref
target="RFC5036">LDP protocol specification</xref>.</t>
<t>To establish a Downstream-on-Demand session between the two access
LSR/ABRs, both should propose the Downstream-on-Demand label
advertisement mode in the Initialization message. If the access LSR
only supports LDP DoD and the access ABR proposes Downstream
Unsolicited mode, the access LSR should send a Notification message
with status "Session Rejected/Parameters Advertisement Mode” and
then close the LDP session as specified in <xref target="RFC5036">LDP
protocol specification</xref>.</t>
<t>If an access LSR is acting in an active role, it should re-attempt
the LDP session immediately. If the access LSR receives the same
Downstream Unsolicited mode again, it should follow the exponential
backoff algorithm as defined in the <xref target="RFC5036">LDP
protocol specification</xref> with delay of 15 seconds and subsequent
delays growing to a maximum delay of 2 minutes.</t>
<t>In case a PWE3 service is required between the adjacent access
LSR/ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the
same LDP session should be used for PWE3 FECs. Even if LDP DoD label
advertisement has been negotiated for IPv4 and IPv6 LDP FECs as
described earlier, LDP session should use Downstream Unsolicited label
advertisement for PWE3 FECs as specified in <xref
target="RFC4447">PWE3 LDP</xref>.</t>
</section>
<section anchor="sec_label_request" title="Label Request Procedures">
<t/>
<section title="Access LSR/ABR Label Request">
<t>Upstream access LSR/ABR will request label bindings from adjacent
downstream access LSR/ABR based on the following trigger events:
<list style="letters">
<t>Access LSR/ABR is configured with /32 static route with LDP
DoD Label Request policy in line with initial network setup use
case described in <xref
target="sec_initial_network_setup"/>.</t>
<t>Access LSR/ABR is configured with a service in line with
service use cases described in <xref
target="sec_service_provisioning_and_activation"/> and <xref
target="sec_service_changes_and_decommissioning"/>.</t>
<t>Configuration with access static routes - Access LSR/ABR link
to adjacent node comes up and LDP DoD session is established. In
this case access LSR should send Label Request messages for all
/32 static routes configured with LDP DoD policy and all /32
routes related to provisioned services that are covered by
default route.</t>
<t>Configuration with access IGP - Access LSR/ABR link to
adjacent node comes up and LDP DoD session is established. In
this case access LSR should send Label Request messages for all
/32 routes learned over the access IGP and all /32 routes
related to provisioned services that are covered by access IGP
routes.</t>
<t>In all above cases requests must be sent to next-hop LSR(s)
and alternate LSR(s).</t>
</list></t>
<t>Downstream access LSR/ABR will respond with Label Mapping message
with a non-null label if any of the below conditions are met: <list
style="letters">
<t>Downstream access LSR/ABR - requested FEC is an IGP or static
route and there is an LDP label already learnt from the
next-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 the next-next-hop downstream LSR, downstream LSR must send a
Label Request message for the same FEC to the next-next-hop
downstream LSR. In such case downstream LSR will respond back to
the requesting upstream access LSR only after getting a label
from the next-next-hop downstream LSR peer.</t>
<t>Downstream access ABR only - requested FEC is a BGP labelled
unicast route <xref target="RFC3107"/> and this BGP route is the
best selected for this FEC.</t>
</list></t>
<t>Downstream access LSR/ABR may respond with a Label Mapping with
explicit-null or implicit-null label if it is acting as an egress
for the requested FEC, or it may respond with “No Route“
notification if no route exists.</t>
</section>
<section anchor="sec_label_request_retry" title="Label Request Retry">
<t>Following LDP specification <xref target="RFC5036">LDP
specification</xref>, if an access LSR/ABR receives a “No
route” Notification in response to its Label Request message,
it should retry using an exponential backoff algorithm similar to
the backoff algoritm mentioned in the LDP session negotiation
described in <xref target="sec_ldp_dod_session_negotiation"/>.</t>
<t>If there is no response to the sent Label Request message, the
<xref target="RFC5036">LDP specification</xref> (section A.1.1,
page# 100) states that the LSR should not send another request for
the same label to the peer and mandates that a duplicate Label
Request is considered a protocol error and should be dropped by the
receiving LSR by sending a Notification message.</t>
<t>Thus, if there is no response from the downstream peer, the
access LSR/ABR should not send a duplicate Label Request message
again.</t>
<t>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 Label Mapping message, then the access LSR/ABR should
send a Label Abort message to the downstream LSR.</t>
<t>To address the case of slower convergence resulting from
described LDP behavior in line with <xref target="RFC5036">LDP
specification</xref>, a new LDP TLV extension is proposed and
described in <xref
target="sec_label_request_with_fast_up_convergence"/>.</t>
</section>
</section>
<section title="Label Withdraw">
<t>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 upstream access LSR/ABR with the Label Withdraw Message <xref
target="RFC5036"/> with a specified label TLV or with an empty label
TLV.</t>
<t>Downstream access LSR/ABR should withdraw a label for specific FEC
in the following cases: <list style="letters">
<t>If LDP DoD ingress label is associated with an outgoing label
assigned by BGP labelled unicast route, and this route is
withdrawn.</t>
<t>If LDP DoD ingress label is associated with an outgoing label
assigned by LDP (DoD or DU) and the IGP route is withdrawn from
the RIB or downstream LDP session is lost.</t>
<t>If LDP DoD ingress label is associated with an outgoing label
assigned by LDP (DoD or DU) and the outgoing label is withdrawn by
the downstream LSR.</t>
<t>If LDP DoD ingress label is associated with an outgoing label
assigned by LDP (DoD or DU), route next-hop changed and <list
style="symbols">
<t>there is no LDP session to the new next-hop. To minimize
probability of this, the access LSR/ABR should implement
LDP-IGP synchronization procedures as specified in <xref
target="RFC5443"/>.</t>
<t>there is an LDP session but no label from downstream LSR.
See note below.</t>
</list></t>
<t>If access LSR/ABR is configured with a policy to reject
exporting label mappings to upstream LSR.</t>
</list></t>
<t>The upstream access LSR/ABR responds to the Label Withdraw Message
with the Label Release Message <xref target="RFC5036"/>.</t>
<t>After sending Label Release message to downstream access LSR/ABR,
the upstream access LSR/ABR should resend Label Request message,
assuming upstream access LSR/ABR still requires the label.</t>
<t>Downstream access LSR/ABR should withdraw a label if the local
route configuration (e.g. /32 loopback) is deleted.</t>
<t>Note: For any events inducing next hop change, downstream access
LSR/ABR should attempt to converge the LSP locally before withdrawing
the 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
by LDP DoD session, then the downstream access LSR/ABR must send a
Label Request on the new next-hop session. If downstream access
LSR/ABR doesn‘t get Label Mapping for some duration, then and
only then downstream access LSR/ABR must withdraw the upstream
label.</t>
</section>
<section title="Label Release">
<t>If an access LSR/ABR does not need any longer a label for a FEC, it
sends a Label Release Message <xref target="RFC5036"/> to the
downstream access LSR/ABR with or without the label TLV.</t>
<t>If upstream access LSR/ABR receives an unsolicited Label Mapping on
DoD session, they should release the label by sending Label Release
message.</t>
<t>Access LSR/ABR should send a Label Release message to the
downstream LSR in the following cases: <list style="letters">
<t>If it receives a Label Withdraw from the downstream access
LSR/ABR.</t>
<t>If the /32 static route with LDP DoD Label Request policy is
deleted.</t>
<t>If the service gets decommissioned and there is no
corresponding /32 static route with LDP DoD Label Request policy
configured.</t>
<t>If the route next-hop changed, and the label does not point to
the best or alternate next-hop.</t>
<t>If it receives a Label Withdraw from a downstream DoD
session.</t>
</list></t>
<t/>
</section>
<section title="Local Repair">
<t>To support local-repair with ECMP and IPFRR LFA, access LSR/ABR
must request labels on both the best next-hop and the alternate
next-hop LDP DoD sessions, as specified in the Label Request
procedures in <xref target="sec_label_request"/>. If remote LFA is
enabled, access LSR/ABR needs a label from its alternate next-hop
toward the PQ node and needs a label from the remote PQ node toward
its FEC/destination. If access LSR/ABR doesn't already know those
labels, it must request them.</t>
<t>This will enable access LSR/ABR to pre-program the alternate
forwarding path with the alternate label(s), and invoke IPFRR LFA
switch-over procedure if the primary next-hop link fails.</t>
<t/>
</section>
</section>
<section anchor="sec_label_request_with_fast_up_convergence"
title="LDP Extension for LDP DoD Fast-Up Convergence">
<t>In some conditions, the exponential backoff algorithm usage described
in <xref target="sec_label_request_retry"/> may result in a longer than
desired wait time to get a successful LDP label to route mapping. An
example is when a specific route is unavailable on the downstream LSR
when the Label Mapping request from the upstream is received, but later
comes back. In such case using the exponential backoff algorithm may
result in a max delay wait time before the upstream LSR sends another
LDP Label Request.</t>
<t>This section describes an extension to the LDP DoD procedure to
address fast-up convergence, and as such should be treated as a
normative reference. The downstream and upstream LSRs SHOULD implement
this extension if the improvement in up convergence is desired.</t>
<t>The extension consists of the upstream LSR indicating to the
downstream LSR that the Label Request SHOULD be queued on the downstream
LSR until the requested route is available.</t>
<t>To implement this behavior, a new Optional Parameter is defined for
use in the Label Request message:</t>
<t><figure align="center">
<artwork><![CDATA[ Optional Parameter Length Value
Queue Request TLV 0 see below
]]></artwork>
<postamble/>
</figure></t>
<t><figure align="center">
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Queue Request (0x0971) | Length (0x00) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit = 1
Unknown TLV bit. Upon receipt of an unknown TLV, due to U-bit
being set (=1), the unknown TLV MUST be silently ignored and the
rest of the message processed as if the unknown TLV did not exist.
In case requested route is not available, the downstream LSR MUST
ignore this unknown TLV and send a "no route" notification back.
Ensures backward compatibility.
F-bit = 0
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
forwarded. Due to F-bit being clear (=0), the unknown TLV is not
forwarded with the containing message.
Type
Queue Request Type value to be allocated by IANA.
Length = 0x00
Specifies the length of the Value field in octets.
]]></artwork>
<postamble/>
</figure></t>
<t>Specified operation is as follows.</t>
<t>To benefit from the fast-up convergence improvement, the upstream LSR
sends a Label Request message with a Queue Request TLV.</t>
<t>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
existing LDP procedures. If the route is not available, the downstream
LSR queues the request and replies as soon as the route becomes
available. In the meantime, it does not send a "no route" notification
back. When sending a Label Request with the Queue Request TLV, the
upstream LSR does not retry the Label Request message if it does not
receive a reply from its downstream peer</t>
<t>If the upstream LSR wants to abort an outstanding Label Request while
the Label Request is queued in the downstream LSR, the upstream LSR
sends a Label Abort Request message, making the downstream LSR to remove
the original request from the queue and send back a notification Label
Request Aborted <xref target="RFC5036"/>.</t>
<t>If the downstream LSR does not support the Queue Request TLV, and
requested route is not available, it ignores this unknown TLV and sends
a "no route" notification back in line with <xref target="RFC5036"/>. In
this case the upstream LSR invokes the exponential backoff algorithm
described in <xref target="sec_label_request_retry"/> following standard
LDP specification <xref target="RFC5036">LDP specification</xref>.</t>
<t>This described procedure ensures backward compatitibility.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t/>
<section title="LDP TLV TYPE">
<t>This document uses a new a new Optional Parameter Queue Request TLV
in the Label Request message defined in <xref
target="sec_label_request_with_fast_up_convergence"/>. IANA already
maintains a registry of name LDP "TLV TYPE NAME SPACE" defined by
RFC5036. The following value is suggested for assignment:</t>
<t><figure align="center">
<artwork><![CDATA[ TLV type Description
0x0971 Queue Request TLV
]]></artwork>
<postamble/>
</figure></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>MPLS LDP Downstream on Demand deployment in the access network is
subject to similar security threats as any MPLS LDP deployment. It is
recommended that baseline security measures are considered as described
in <xref target="RFC5920">Security Framework for MPLS and GMPLS
networks</xref> and the <xref target="RFC5036">LDP specification</xref>
including ensuring authenticity and integrity of LDP messages, as well
as protection against spoofing and Denial of Service attacks.</t>
<t>Some deployments may require increased measures of network security
if a subset of Access Nodes are placed in locations with lower levels of
physical security e.g. street cabinets (common practice for VDSL
access). In such cases it is the responsibility of the system designer
to take into account the physical security measures (environmental
design, mechanical or electronic access control, intrusion detection),
as well as monitoring and auditing measures (configuration and Operating
System changes, reloads, routes advertisements).</t>
<t>But even with all this in mind, the designer still should consider
network security risks and adequate measures arising from the lower
level of physical security of those locations.</t>
<section title="Security and LDP DoD">
<t/>
<section title="Access to network packet flow direction">
<t>An important property of MPLS LDP Downstream on Demand operation
is that the upstream LSR (requesting LSR) accepts only mappings it
sent a request for (in other words the ones it is interested in),
and does not accept any unsolicited label mappings by design.</t>
<t>This limits the potential of an unauthorized third party fiddling
with label mappings operations on the wire. It also enables ABR LSR
to monitor behaviour of any Access LSR in case the latter gets
compromised and attempts to get access to an unauthorized FEC or
remote LSR. Note that ABR LSR is effectively acting as a gateway to
the MPLS network, and any Label Mapping requests made by any Access
LSR are processed and can be monitored on this ABR LSR.</t>
</section>
<section title="Network to access packet flow direction">
<t>Another important property of MPLS LDP DoD operation in the
access is that the number of access nodes and associated MPLS FECs
per ABR LSR is not large in number, and they are all known at the
deployment time. Hence any changes of the access MPLS FECs can be
easily controlled and monitored on the ABR LSR.</t>
<t>And then, even in the event when Access LSR manages to advertise
a FEC that belongs to another LSR (e.g. in order to
‘steal’ third party data flows, or breach a privacy of
VPN), such Access LSR will have to influence the routing decision
for affected FEC on the ABR LSR. Following measures should be
considered to prevent such event from occurring:</t>
<t><list style="letters">
<t>ABR LSR - access side with static routes - this is not
possible for Access LSR. Access LSR has no way to influence ABR
LSR routing decisions due to static nature of routing
configuration here.</t>
<t>ABR LSR – access side with IGP - this is still not
possible if the compromised Access LSR is a leaf in the access
topology (leaf node in topologies I1, I, V, Y described earlier
in this document), due to the leaf metrics being configured on
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
possible for this Access LSR to attract to itself traffic
destined to the nodes upstream from it. However elaborate such
‘man in the middle attack’ is possible, but can be
quickly detected by upstream Access LSRs not receiving traffic,
and legitimate traffic from them getting dropped.</t>
<t>ABR LSR - network side - designer should consider giving a
higher administrative preference to the labeled unicast BGP
routes vs. access IGP routes.</t>
</list></t>
<t>In summary MPLS in access design with LDP DoD has number of
native properties that prevent number of security attacks and make
their detection quick and straightforward.</t>
<t>Following two sections describe other security considerations
applicable to general MPLS deployments in the access.</t>
</section>
</section>
<section title="Data Plane Security">
<t>Data plane security risks applicable to the access MPLS network are
listed below (a non-exhaustive list):</t>
<t><list style="letters">
<t>packets from a specific access node flow to an altered
transport layer or service layer destination.</t>
<t>packets belonging to undefined services flow to and from the
access network.</t>
<t>unlabelled packets destined to remote network nodes.</t>
</list>Following mechanisms should be considered to address listed
data plane security risks:</t>
<t><list style="numbers">
<t>addressing (a) - Access and ABR LSRs should NOT accept labeled
packets over a particular data link, unless from the Access or ABR
LSR perspective this data link is known to attach to a trusted
system based on employed authentication mechanism(s), and the top
label has been distributed to the upstream neighbour by the
receiving Access or ABR LSR.</t>
<t>addressing (a) – ABR LSR MAY restrict network
reachability for access devices to a subset of remote network LSR,
based on authentication or other network security technologies
employed towards Access LSRs. Restricted reachability can be
enforced on the ABR LSR using local routing policies, and can be
distributed towards the core MPLS network using routing policies
associated with access MPLS FECs.</t>
<t>addressing (b) - labeled service routes (e.g. MPLS/VPN, tLDP)
are not accepted from unreliable routing peers. Detection of
unreliable routing peers is achieved by engaging routing protocol
detection and alarm mechanisms, and is out of scope of this
document.</t>
<t>addressing (a) and (b) - no successful attacks have been
mounted on the control plane and has been detected.</t>
<t>addressing (c) - ABR LSR MAY restrict IP network reachability
to and from the access LSR.</t>
</list></t>
</section>
<section title="Control Plane Security">
<t>Similarly to <xref target="RFC4364">Inter-AS MPLS/VPN
deployments</xref>, the control plane security is prerequisite to the
data plane security.</t>
<t>To ensure control plane security access LDP DoD sessions should
only be established with LDP peers that are considered trusted from
the local LSR perspective, meaning they are reachable over a data link
that is known to attach to a trusted system based on employed
authentication mechanism(s) on the local LSR.</t>
<t>The security of LDP sesions is analyzed in <xref
target="I-D.ietf-karp-routing-tcp-analysis"/>, and its reading is
recommended. Specifically the <xref target="RFC5925">TCP/IP MD5
authentication option</xref> should be used with LDP as described in
<xref target="RFC5036">LDP specification</xref>. If TCP/IP MD5
authentication is considered not secure enough, the designer may
consider using a more elaborate and advanced TCP Authentication Option
<xref target="RFC5925">TCP-AO</xref> for LDP session
authentication.</t>
<t>Access IGP (if used) and any routing protocols used in access
network for signaling service routes should also be secured in a
similar manner. Refer to <xref
target="I-D.ietf-karp-routing-tcp-analysis"/> and <xref
target="RFC6863"/> for further analysis of security properties of
IS-IS and OSPF IGP routing protocols.</t>
<t>For increased level of authentication in the control plane security
for a subset of access locations with lower physical security,
designer could also consider using:</t>
<t><list style="symbols">
<t>different crypto keys for use in authentication procedures for
these locations.</t>
<t>stricter network protection mechanisms including DoS
protection, interface and session flap dampening.</t>
</list></t>
</section>
<section title="Network Node Security">
<t>If a network node, especially an Access Node, is not located in a
physically secured and controlled location, then this Access Node
should implement some measures to provide a level of protection of the
key(s) used to its authenticate to the network, so as to avoid an
attacker to get those keys easily. Software tools should monitor and
keep checking the integrity of the Access Node configuration and
software version. Note that this is not specific to the node using LDP
DoD. In the contrary, the use of LDP DoD will allow the
upstream/network to check, log and possibly deny the FEC requests from
the Access Node.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai
Leymann, Geraldine Calvignac, Ina Minei, Eric Gray and Lizhong Jin for
their suggestions and review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.5036'?>
<?rfc include='reference.RFC.4447'?>
<?rfc include='reference.RFC.4364'?>
<?rfc include='reference.RFC.3031'?>
<?rfc include='reference.RFC.5283'?>
<?rfc include='reference.RFC.5920'?>
<?rfc include='reference.I-D.ietf-mpls-seamless-mpls'?>
</references>
<references title="Informative References">
<?rfc ?>
<?rfc include='reference.RFC.3107'?>
<?rfc include='reference.RFC.5443'?>
<?rfc include='reference.RFC.5925'?>
<?rfc include='reference.RFC.6863'?>
<?rfc include='reference.I-D.ietf-karp-routing-tcp-analysis'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 17:32:47 |