| Open Shortest Path First IGP | H. Gredler, Ed. |
| Internet-Draft | Juniper Networks, Inc. |
| Intended status: Standards Track | S. Amante |
| Expires: October 15, 2013 | Level 3 Communications, Inc. |
| T. Scholl | |
| Amazon | |
| L. Jalil | |
| Verizon | |
| April 13, 2013 |
Advertising MPLS labels in OSPF
draft-gredler-ospf-label-advertisement-00
Historically MPLS label distribution was driven by protocols like LDP, RSVP and LBGP. All of those protocols are session oriented. In order to obtain label binding for a given destination FEC from a given router one needs first to establish an LDP/RSVP/LBGP session with that router.
Advertising MPLS labels in IGPs advertisement [I-D.gredler-rtgwg-igp-label-advertisement] describes several use cases where utilizing the flooding machinery of link-state protocols for MPLS label distribution allows to obtain the binding without requiring to establish an LDP/RSVP/LBGP session with that router.
This document describes the protocol extension to distribute MPLS labels by the OSPFv2 and OSPFv3 protocol.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 15, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
MPLS label allocations are predominantly distributed by using the LDP [RFC5036], RSVP [RFC5151] or labeled BGP [RFC3107] protocol. All of those protocols have in common that they are session oriented, which means that in order to obtain label binding for a given destination FEC from a given router one needs first to establish a direct control plane (LDP/RSVP/LBGP) session with that router.
There are a couple of use cases [I-D.gredler-rtgwg-igp-label-advertisement] where the consumer of a MPLS label binding may not be adjacent to the router that performs the binding. Bringing up an explicit session using the existing label distribution protocols between the non-adjacent router that bind the label and the router that acts as a consumer of this binding is the existing remedy for this dilemma.
This document describes a OSPFv2 and OSPFv3 protocol extension which allows routers to advertise MPLS label bindings within and beyond an IGP domain, and controlling inter-area distribution.
Distributing MPLS labels in an IGP (IS-IS) has been described in Segment Routing [I-D.previdi-filsfils-isis-segment-routing]. The authors propose to re-use existing traffic-engineering extensions for carrying the label information. While retrofitting existing protocol machinery for new purposes is generally a good thing, Segment Routing [I-D.previdi-filsfils-isis-segment-routing] falls short of addressing some use-cases defined in [I-D.gredler-rtgwg-igp-label-advertisement].
The dominant issue around re-using traffic-engineering extensions is that both have existing protocol semantics, which might not be applicable to advertising MPLS label switched paths in a generic fashion. These are specifically:
'Bi-directionality semantics', affects the complexity around advertisement of unidirectional LSPs. Label advertisement of per-link labels or 'Adj-SIDs' [I-D.previdi-filsfils-isis-segment-routing] is done by attaching label information to adjacency advertisment TLVs. Usually implementations need to have an adjacency in 'Up' state prior to advertising this adjacency as TE-Link in its Link State advertisment. In order to advertise a per-link LSP an implementation first needs to have an adjacency, which only transitions to 'Up' state after passing the 3-way check. This implies bi-directionality. If an implementation wants to advertise per-link MPLS LSPs to e.g. outside the IGP domain then it would need to fake-up an adjacency. Changing existing IGP Adjacency code to support such cases defeats the purpose of re-using existing functionality as there is not much common functionality to be shared.
LSPs pointing to a Node are advertised as 'Node-SIDs' [I-D.previdi-filsfils-isis-segment-routing] using IP Prefix containers. That means that in order to advertise a MPLS LSP, one is inheriting the semantics of advertising an IP path. Consider router A has got existing LSPs to its entire one-hop neighborhood and is re-advertising those LSPs using IP reachability semantics. Now we have two exact matching IP advertisements. One from the owning router (router B) which advertises its stable transport loopback address and another one from router A re-advertising a LSP path to router B. Existing routing software may get confused now as the 'stable transport' address shows up from multiple places in the network and more worse the IP forwarding path for control-plane protocols may get mingled with the MPLS data plane.
Both exisiting traffic-engineering extension containers have limited semantics describing MPLS label-switched paths in the sense of a 'path'. Both encoding formats allow to express a pointer to some specific router, but not to describe a MPLS label switched path containing all of its path segments. [I-D.previdi-filsfils-isis-segment-routing] allows to define 'Forwarding Adjacencies' as per [RFC4206]. The way to describe a path of a given forwarding adjacency is to enlist a list of "Segment IDs". That implies that nodes which do not yet participate in 'Segment routing' or are outside of a 'Segment routing' domain can not be expressed using those path semantics.
A protocol for advertising MPLS label switched paths, should be generic enough to express paths sourced by existing MPLS LSPs, such that ingress routers can flexibly combine them according to application needs.
IGP advertisement of MPLS label switched paths requires a new set of protocol semantics (undirectional paradigm, path paradigm), which hardly can be expressed using the existing OSPF and OSPF-TE protocol semantics. This document describes protocol extensions which allows generic advertisement of MPLS label switched paths in OSPF.
One new LSA is defined, the MPLS Label LSA. This LSA advertises MPLS labels along with their path information. The LSA contains more specific information encoded in TLVs. Those TLV extensions are shared between the OSPFv2 and OPSFv3 protocols.
The LSA ID of an Opaque LSA is defined as having eight bits of type data and 24 bits of type-specific data. The MPLS Label LSA uses type 149. The remaining 24 bits are 4 zero bits followed by the MPLS Label value as follows:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 149 |0|0|0|0| MPLS Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MPLS LSA-ID format
The 'MPLS Label' field holds the 20 Bit MPLS label. Therefore a maximum of 2^20 MPLS Label LSAs may be sourced by a single system.
This extension makes use of the Opaque LSAs [RFC5250].
Three types of Opaque LSAs exist, each of which has a different flooding scope. This proposal uses only Type 10 LSAs, which have an area flooding scope.
The MPLS Label LSA for OSPFv2 starts with the standard OSPFv2 LSA header:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 149 |0|0|0|0| MPLS Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- TLVs -+ | ... |
Figure 2: MPLS Label OSPFv2 LSA format
The OSPFv3 LSA ID of an MPLS Label LSA is defined as having twelve bits of zero followed by the 20-Bit label MPLS Label value as follows:
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|0|0|0|0|0|0|0|0|0|0|0| MPLS Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MPLS OSPFv3 LSA-ID format
The 'MPLS Label' field holds the 20 Bit MPLS label. Therefore a maximum of 2^20 MPLS Label LSAs may be sourced by a single system.
The MPLS Label LSA for OSPFv3 starts with the standard OSPFv3 LSA header:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |1|0|1| 149 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0|0|0|0|0| MPLS Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- TLVs -+ | ... |
Figure 4: MPLS Label OSPFv3 LSA format
The OSPFv3 'U' Bit will always be set such that routers which do not understand the new MPLS Label LSA will store and forward it further.
In analogy to the OSPFv2 opaque LSA 10 the flooding scope will be set to 'Area scoping'.
The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets for extensibility. The format of each TLV is:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: TLV format
The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored.
This memo defines Types 1, 2 and 3. See the IANA Considerations section for allocation of new Types.
The MPLS Label LSA may be originated by any Traffic Engineering [RFC3630] capable router in an OSPF domain. A router may advertise MPLS labels along with so called 'ERO' path segments describing the label switched path. This gets encoded in subsequent TLVs. Since ERO style path notation allows to express pointers to link and node IP addresses. Now any label switched path, sourced by any protocol, can be described.
An LSA contains one or more TLVs, describing properties of the advertised MPLS label.
The following TLV extensions may be shared in both OSPV2 and OSPFv3. Passing an IP address of the other address family (IPv4 in OPSFv3 or IPv6 in OSPFv2) is possible as the information carried are related describing the hops along a path. The receiver of this information is a protocol agnostic path computation module.
All 'Prefix ERO' information represents an ordered set which describes the segments of a label-switched path. The last Prefix ERO TLV describes the segment closest to the egress point of the LSP. Contrary the first Prefix ERO TLV describes the first segment of a label switched path. If a router extends or stitches a label switched path it MUST prepend the new segments path information to the Prefix ERO list.
The IPv4 ERO TLV (Type 1) describes a path segment using IPv4 Prefix style of encoding. Its appearance and semantics have been borrowed from Section 4.3.3.2 [RFC3209].
the 'IPv4 Address' is treated as a prefix based on the prefix length value below. Bits beyond the prefix are ignored on receipt and SHOULD be set to zero on transmission.
The 'Prefix Length' field contains the length of the prefix in bits.
The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.'
The 'Reserved' bits are for future use. They should be zero on transmission and ignored on receipt.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length |L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPv4 Prefix ERO TLV format
The IPv6 ERO TLV (Type 2) describes a path segment using IPv6 Prefix style of encoding. Its appearance and semantics have been borrowed from Section 4.3.3.2 [RFC3209].
the 'IPv6 Address' is treated as a prefix based on the prefix length value below. Bits beyond the prefix are ignored on receipt and SHOULD be set to zero on transmission.
The 'Prefix Length' field contains the length of the prefix in bits.
The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.'
The 'Reserved' bits are for future use. They should be zero on transmission and ignored on receipt.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length |L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IPv6 Prefix ERO TLV format
The Flags TLV (Type 3) describes Flags for further MPLS LSA treatment.
Up/Down 'U' Bit: A router may flood MPLS label information across area boundaries. In order to prevent flooding loops, a router will Set the Up/Down (U-Bit) when propagating MPLS labels from Area 0 to a non-zero Area.
The 'Reserved' bits are for future use. They should be zero on transmission and ignored on receipt.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Flags TLV format
The following topology [sample-topology] and IP addresses shall be used throughout the Label advertisement examples.
AS1 : AS 2
:
: :
Level 1 : Level 2 :
: :
+-----+ +-----+-IP3--IP4--+-----+ :
| R1 +-IP1--IP2--+ R2 | | R3 | :
+--+--+ +--+--+-IP5--IP6--+--+--+-IP15-IP16-
| | | : \
IP3 IP7 IP13 : +--+--+
| | | : | R7 |
IP4 IP8 IP14 : +--+--+
| | | : /
+--+--+ +--+--+ +--+--+-IP17-IP18-
| R4 +-IP19-IP20-+ R5 |-IP11-IP12-| R6 | :
+-----+ +-----+ +-----+ :
: :
: :
: :
Figure 9: Sample Topology
If R1 would advertise a label <N> bound to a one-hop LSP from R1 to R2 it would encode as follows:
If R2 would advertise a label <N>bound to a one-hop LSP from R2 to R3, using the link #2 it would encode as follows
If R3 would advertise a label <N> bound to a one-hop LSP from R3 to R7 (which is outside of the IGP domain), it would encode as follows:
As you can see the representation of an MPLS label crossing an external link is identical as an internal link Section 5.2.
Consider a RSVP LSP name "R2-to-R6" traversing (R2 to R3 using link #1, R6):
If R2 would advertise a label <N> bound to the RSVP LSP named 'R2-to-R6', it would encode as follows
Consider R2 that creates a LDP label binding for FEC 172.16.0.0./12 using label <N>.
If R2 would re-advertise this binding in IS-IS it would encode as follows
Consider two R2->R6 paths: {R2, R3, R6} and {R2, R5, R6}
Consider two R5->R3 paths: {R5, R2, R3} and {R5, R6, R3}
R2 encodes its two paths to R6 as follows:
R5 encodes its two paths to R3 as follows:
A receiving non-backbone router does see now all 4 paths and may decide to load-balance across all or a subset of them.
Propagation of a MPLS LSP across an area boundary is a local policy decision.
If local policy dictates that a given ABR router needs to re-advertise a MPLS LSPs from one area to another then it MUST allocate a new label and program its label forwarding table to connect the new label to the path in the respective other area. Depending on how to reach the re-advertised LSP, this is typically done using a MPLS 'SWAP' or 'SWAP/PUSH' data plane operation.
If local policy dictates that a given ABR router needs to re-advertise a MPLS LSPs from one area to another then it must prepend its "Traffic-Engineering-ID" as a loose hop in the Prefix ERO TLV list. Furthermore it MUST append teh Flags TLV and set the 'Down' Bit.
Many thanks to Yakov Rekhter for his useful comments.
This documents request allocation for one common OSPFv2 and OSPFv3 LSA Type and TLVs contained within.
| LSA | TLV | LSA Type | TLV Type | #Occurence |
|---|---|---|---|---|
| MPLS Label | 149 | >=0 | ||
| IPv4 Prefix ERO | 1 | >=0 | ||
| IPv6 Prefix ERO | 2 | >=0 | ||
| Flags | 3 | 0,1 |
The MPLS Label LSA requires a new sub-registry, with a starting TLV value of 1, and managed by Expert Review.
This document does not introduce any change in terms of OSPF security. It simply proposes to flood MPLS label information via the IGP. All existing procedures to ensure message integrity do apply here.
| [I-D.gredler-rtgwg-igp-label-advertisement] | Gredler, H., Amante, S., Scholl, T. and L. Jalil, "Advertising MPLS labels in IGPs", Internet-Draft draft-gredler-rtgwg-igp-label-advertisement-03, April 2013. |
| [I-D.previdi-filsfils-isis-segment-routing] | Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M., Decraene, B., Litkowski, S., Milojevic, I., Shakir, R., Ytti, S., Henderickx, W. and J. Tantsura, "Segment Routing with IS-IS Routing Protocol", Internet-Draft draft-previdi-filsfils-isis-segment-routing-02, March 2013. |