RFC 5251
Layer 1 VPN Basic Mode
Status of This Memo 🎀
okay so this doc is an Internet standards track protocol spec for the Internet community 💖 It's inviting discussion and suggestions for improvements, bestie. If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨ And distribution of this memo is unlimited 🌈
Abstract 🦋
so this document is all about the Basic Mode of Layer 1 VPNs (L1VPNs) 💅 L1VPN Basic Mode (L1VPN BM) is a port-based VPN 🫶 The basic unit of service is a Label Switched Path (LSP) between a pair of customer ports inside a given VPN port topology. It's giving clean and simple 🍓 The doc defines the operational model using either provisioning or a VPN auto-discovery mechanism, plus the signaling extensions for the L1VPN BM 👑
Table of Contents 🌸
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Layer 1 VPN Service .............................................4
3. Addressing, Ports, Links, and Control Channels ..................7
3.1. Service Provider Realm .....................................7
3.2. Layer 1 Ports and Index ....................................7
3.3. Port and Index Mapping .....................................8
4. Port-Based L1VPN Basic Mode ....................................10
4.1. L1VPN Port Information Tables .............................11
4.1.1. Local Auto-Discovery Information ...................12
4.1.2. PE Remote Auto-Discovery Information ...............12
4.2. CE-to-CE LSP Establishment ................................14
4.3. Signaling .................................................15
4.3.1. Signaling Procedures ...............................15
4.3.1.1. Shuffling Sessions ........................16
4.3.1.2. Stitched or Nested Sessions ...............17
4.3.1.3. Other Signaling ...........................18
4.4. Recovery Procedures .......................................19
5. Security Considerations ........................................20
6. References .....................................................21
6.1. Normative References ......................................21
6.2. Informative References ....................................22
7. Acknowledgments ................................................23🧚 Part 1 of 6 (this is the title block, status, abstract, TOC, and sections 1 to 1.1). The rest is coming, so stay tuned, bestie 💜
1. Introduction ✨
okay so this section describes the Basic Mode of Layer 1 VPNs (L1VPN BM) that is outlined in [RFC4847] 💖 The applicability of Layer 1 VPNs is covered in [RFC5253] 🎀 Here we're looking at a layer 1 service provider network made of devices that support GMPLS (for example, Lambda Switch Capable (LSC) devices, optical cross-connects, Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) cross-connects, and so on) 🌈
We split these devices into P (provider) and PE (provider edge) devices 💅 In this doc, the former are just called "P" and the latter are just called "PE" ✨ The Ps only connect to devices inside the provider's network 🫶 The PEs connect to the other devices in the network (either Ps or PEs) and also to devices outside the service provider network 🦋 We call those outside devices Customer Edge (CE) devices 💜 An example of a CE would be a GMPLS-enabled device that is a router, an SDH cross-connect, or an Ethernet switch 🍓
[RFC4208] defines signaling from the CE to the PE 🧚 In [RFC4208], the term "Core Node (CN)" lines up with P and PE nodes, and "Edge Node (EN)" lines up with CE nodes 👑 We also define an "edge Core Node", which is the PE 💅
Figure 1 shows the components in an L1VPN network 🦋
+---+ +---+
| P |....| P |
+---+ +---+
/ \
+-----+ +-----+ +--+
+--+ | PE | | |----| |
|CE|----| | | | |CE|
+--+\ +-----+ | |----| |
\ | | PE | +--+
\ +-----+ | |
\| PE | | | +--+
| | | |----|CE|
+-----+ +-----+ +--+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
Figure 1: Generalized Layer 1 VPN Reference ModelThis document explains how the L1VPN Basic Mode service can be realized using off-line provisioning or VPN auto-discovery, plus Generalized Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471], [RFC3473], Routing [RFC4202], and LMP [RFC4204] mechanisms 🌸
L1VPN auto-discovery has similar requirements [RFC4847] to L3VPN auto-discovery 💖 Just like with L3VPNs, there are protocol choices to make with auto-discovery 🫶 Section 4.1.1 covers the information that needs to be discovered ✨
GMPLS routing and signaling are used without extensions inside the service provider network to set up and maintain LSC or SONET/SDH (Time Division Multiplexing (TDM)) connections between service provider nodes 🎀 This follows the model in [RFC4208] 💅
In L1VPN Basic Mode, LMP helps fill in the Port Information Tables of the service provider 🌈 LMP MAY be used as an option to automate local CE-to-PE link discovery 👑 LMP also MAY augment routing (in enhanced mode) as well as failure handling capabilities 🧚
Consideration of inter-AS and inter-provider L1VPNs needs more analysis and is beyond the scope of this document 🥺💀
1.1. Conventions Used in This Document 💜
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] 🫶
This document assumes you're already familiar with the terminology defined and used in [RFC3945], [RFC3471], [RFC3473], [RFC3477], [RFC4201], [RFC4202], [RFC4204], [RFC4208], and the documents referenced in those 📚💅
2. Layer 1 VPN Service ✨
okay so bestie, layer 1 VPN services on the interfaces of customer and service provider ports MAY be any of the Layer 1 interfaces GMPLS supports 💅 and since these mechanisms use GMPLS as the signaling mechanism, and GMPLS covers both SONET/SDH (TDM) and LSC interfaces, L1VPN services include (but are not restricted to) LSC- or TDM-based equipment 🔥 this doc is describing Basic Mode L1VPNs, so it requires that:
- GMPLS RSVP-TE is used for signaling both within the service provider (between PEs), as well as between the customer and the service provider (between CE and PE);
- GMPLS Routing on the CE-to-PE link is outside the scope of the Basic Mode of operation of L1VPN; see [RFC4847].
A CE is connected to a PE via one or more links 🦋 in this doc, a link is a GMPLS Traffic Engineering (TE) link construct, as defined in [RFC4202]. a TE link is a logical construct that is a member of a VPN, which brings in the idea of membership to a set of CEs forming the VPN 👑 the interfaces at each end of a link are limited to either TDM or LSC, as supported by GMPLS. more specifically, a <CE, PE> link MUST be of the type <X, LSC> or <Y, TDM>, where X = PSC (Packet Switch Capable), L2SC (Layer 2 Switch Capable), or TDM and Y = PSC or L2SC. in case the LSP is not terminated by the CE, X MAY also = LSC and Y = TDM. one application of an L1VPN connection is to provide a "virtual private lambda" or something similar 🌈 in this case the CE is truly the endpoint in GMPLS terms, so its switching capability on the TE link doesn't matter (although its Generalized Protocol Identifier (GPID) MUST be signaled and identical at both CEs, i.e., head-end and tail-end CE) 🫶
likewise, PEs could be any Layer 1 devices that GMPLS supports (e.g., optical cross-connects, SDH cross-connects), while CEs MAY be devices at layers 1, 2, and 3, such as an SDH cross-connect, an Ethernet switch, and a router, respectively) 🧚
each TE link MAY consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot, respectively) 🌸 for the purpose of this discussion, all the channels within a given link MUST have similar shared characteristics (e.g., switching capability, encoding, type, etc.), and MAY be selected independently from the CE's point of view. channels on different links of a CE don't need to have the same characteristics 🍓
there MAY be more than one TE link between a given CE-PE pair. a CE MAY be connected to more than one PE (with at least one port per PE). and, the other way around, a PE MAY have more than one CE from different VPNs connected to it 💜
if a CE is connected to a PE via multiple TE links and all the links belong to the same VPN, these links (referred to as component links) MAY be treated as a single TE link using the link bundling constructs [RFC4201] ✨
in order to satisfy the requirements of the L1VPN Basic Mode, it is REQUIRED that, for a given CE-PE pair, at least one of the links between them has at least one data bearing channel and at least one control bearing channel, or that there is IP reachability between the CE and the PE that could be used to exchange control information 🙈
a point-to-point link has two end-points: one on the CE and one on the PE. this document refers to the former as "CE port" and to the latter as "PE port" 🎀 so a CE is connected to a PE via one or more ports, where each port MAY consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot, respectively), and all the channels within a given port have shared similar characteristics and can be interchanged from the CE's point of view. just like the definition of a TE link, in this doc ports are logical constructs used to represent a grouping of physical resources that connect a CE to a PE on a per-L1VPN basis 💖
at any point in time, a given port on a PE is associated with at most one L1VPN or, to be more precise, with at most one Port Information Table maintained by the PE (although different ports on a given PE could be associated with different L1VPNs, or, to be more precise, with different Port Information Tables) 🦋 the association of a port with a VPN MAY be defined by provisioning the relationship on the service provider devices. in other words, VPN membership in Basic Mode is enforced through service provider control 🔥
it is REQUIRED that the interface (the one between the CE and PE that is used for signaling) be capable of initiating/processing GMPLS protocol messages [RFC3473] and of following the procedures described in [RFC4208] 💅
an important goal of L1VPN service is supporting what's known as "single-ended provisioning," where adding a new port to a given L1VPN involves configuration changes only on the PE that has this port 👑 extending this model to the CE is outside the scope of the L1VPN BM 🌈
another important goal of L1VPN service is being able to establish/terminate an LSP between a pair of (existing) ports within an L1VPN from the CE devices, without involving configuration changes in any of the service provider's devices 🫶 in other words, the VPN topology is under CE device control (assuming the underlying PE-to-PE connectivity is provided and allowed by the network) ✨
the mechanisms outlined in this document aim to achieve the above goals 🧚 specifically, as part of the L1VPN service offering, these mechanisms (1) enable the service provider to restrict the set of ports to which a given port could be connected, and (2) enable a CE to establish the actual LSP to a subset of ports 🍓 finally, the mechanisms allow arbitrary L1VPN topologies to be supported, including topologies ranging from hub-and-spoke to full mesh point-to-point connections. only point-to-point links are supported 💜
the exchange of CE routing or topology information with the service provider is out of scope for L1VPN BM mode 🙈
3. Addressing, Ports, Links, and Control Channels 🎀
GMPLS-established conventions for addressing and link numbering are discussed in [RFC3945] 🌸 this section builds on those definitions for the L1VPN case, where we now have customer and service provider addresses in a Layer 1 context 💖
3.1. Service Provider Realm
It is REQUIRED that a service provider, or a group of service providers that collectively offer L1VPN service, have a single addressing realm that spans all PE devices involved in providing the L1VPN service 👑 this is necessary to enable GMPLS mechanisms for path establishment and maintenance. we'll call this realm the service provider addressing realm. it is further REQUIRED that each L1VPN customer have its own addressing realm, with complete freedom to use private or public addresses 🦋 we'll call these realms the customer addressing realms. customer addressing realms MAY overlap addresses (i.e., non-unique addresses) with each other, and MAY also overlap addresses with the service provider realm 🔥
3.2. Layer 1 Ports and Index
within a given L1VPN, each port on a CE that connects the CE to a PE has an identifier that is unique within that L1VPN (but doesn't need to be unique across several L1VPNs) 🌈 one way to build such an identifier is to give each port an address that is unique within a given L1VPN and use that address as the port identifier. another way is to give each port on a CE an index that is unique within that CE, give each CE an address that is unique within a given L1VPN, and then use a tuple <port index, CE address> as the port identifier. note that both the port and the CE address MAY be an address in several formats, including but not limited to IPv4 and IPv6 💅 this identifier is part of the Customer addressing Realm and is used by the CE device to identify the CE port and the CE remote port for signaling. CEs don't know or understand service provider realm addresses 🫶
within a service provider network, each port on a PE that connects that PE to a CE has an identifier that is unique within that network 🧚 one way to build it is to give each port on a PE an index that is unique within that PE, give each PE an IP address that is unique within the service provider addressing realm, and then use a tuple <port index, PE IPv4 address> or <port index, PE IPv6 address> as the port identifier within the service provider network. another way is to assign an IPv4 or IPv6 address that is unique within the service provider addressing realm to each such port. either way, this IPv4 or IPv6 address is internal to the service provider network and is used for GMPLS signaling within it 🍓
so each link connecting the CE to the PE is associated with a CE port that has a unique identifier within a given L1VPN, and with a PE port that has a unique identifier within the service provider network 💜 we'll refer to the former as the Customer Port Identifier (CPI), and to the latter as the Provider Port Identifier (PPI) ✨
3.3. Port and Index Mapping 🦋
okay so every PE port that has a PPI ALSO needs its own identifier, and that identifier has to be unique within the L1VPN customer addressing realm of the L1VPN that port belongs to 💖 There are two ways to build one. You can give each port an address that's unique in that customer realm and use that address as the identifier. Or you can give each port an index that's unique within its PE, give each PE an IP address that's unique within the customer realm (it doesn't have to be unique across the whole SP network 👀), and then use the tuple <port index, PE IP address> as the identifier. That second one is called the VPN-PPI ✨. Check out Figure 2 below 🌸
For L1VPNs, it's a requirement that service provider operations stay independent of the VPN customer's addressing realm, and that the service provider addressing realm stays hidden from the customer 🙈 To pull that off, the PE gets two identifiers: one that faces the customer and one that faces the service provider. The PE IP address used for the VPN-PPI is separate from the PE IP address used for the PPI, because they come from different address realms. The former is from the customer's addressing realm and the latter is from a VPN service provider's addressing realm. If a port on a PE has an unnumbered PPI and an unnumbered VPN-PPI, they could both use exactly the same port index. That's just for convenience, since the PPI and VPN-PPI can be in any combination of valid formats 💅
(Customer realm)
+----+ +----+
| |<Port Index> <Port Index> | |
| |CPI VPN-PPI | |
---| CE |-----------------------------| PE |---
| | <Port Index> | |
| | PPI | |
+----+ +----+
(Provider realm)Figure 2: Customer/Provider Port/Index Mapping
Also, as I said earlier, the IP addresses used for the CPIs, PPIs, and VPN-PPIs could be either IPv4 or IPv6 format addresses 🎀
For a given link connecting a CE to a PE:
- If the CPI is an IPv4 address, then the VPN-PPI MUST be an IPv4 address as well, since VPN-PPIs are created from the customer address space. If the CPI is a
<port index, CPI IPv4 address>tuple, then the VPN-PPI MUST be a<port index, PE IPv4 address>tuple for the same reason. - If the CPI is an IPv6 address, then the VPN-PPI MUST be an IPv6 address as well, since VPN-PPIs are created from the customer address space. If the CPI is a
<port index, CPI IPv6 address>tuple, then the VPN-PPI MUST be a<port index, PE IPv6 address>tuple for the same reason.
Note: for a given port on the PE, whether that port's VPN-PPI is an IP address or a <port index, PE IP address> tuple doesn't depend on the format of that port's PPI 🧚
This document assumes the PPIs are assigned only by the service provider, with no coordination with the L1VPN customers 🍓 The CPIs and VPN-PPIs get their addresses only from the administrators of the L1VPN. That gives maximum flexibility ✨ The L1VPN administrator is the entity that controls the L1VPN service specifics for the L1VPN customers. The service provider can own this function, but a third party with an agreement with the service provider can also handle it. And of course, each L1VPN customer could assign those addresses on its own, with no coordination with other L1VPNs 👑
This document also needs IP connectivity between the CE and the PE, as specified earlier. That connectivity is used for the control channel between the CE and the PE 💜 It could be a single IP hop, which could be done with either a dedicated link or an L2VPN, or it could be an IP private network, like an L3VPN. The only requirement on this connectivity is an unambiguous way to correlate a particular CE-to-PE control channel with a particular L1VPN. When the channel is a dedicated link, that link should be associated with a particular L1VPN. When the channel is an L2VPN, a distinct L2VPN should be associated with an L1VPN. When the channel is an L3VPN, a distinct L3VPN should be associated with an L1VPN 🌈
We'll call the CE's address for this channel the CE Control Channel Address (CE-CC-Addr), and the PE's address for this channel the PE Control Channel Address (PE-CC-Addr). Both CE-CC-Addr and PE-CC-Addr are REQUIRED to be unique within the L1VPN they belong to, but they are not REQUIRED to be unique across multiple L1VPNs. Control channel addresses are never shared between VPNs 🙅♀️ The administrators of the L1VPN control how CE-CC-Addr and PE-CC-Addr get assigned 💖
Multiple ports on a CE could share the same control channel, but only as long as all of those ports belong to the same L1VPN. The same goes for multiple ports on a PE: they could share the same control channel only as long as all of them belong to the same L1VPN 🫶
4. Port-Based L1VPN Basic Mode 🎀
okay so an L1VPN is a port-based VPN service, where a pair of CEs can be connected through the service provider network via a GMPLS-based LSP inside a given VPN port topology 🔥 That LSP is literally the basic unit of the L1VPN service that the service provider network offers, so it's the main character 👑 If a port that connects a CE to a PE has multiple channels (for example, multiple wavelengths), the CE could set up LSPs to multiple other CEs in the same VPN over that single port 🌸
In the L1VPN, the service provider does NOT start creating an LSP between a pair of CE ports. The CE starts that LSP instead 🙈 Still, the SP uses the mechanisms and toolkit from this document to limit which other CE ports can be the remote endpoints of LSPs that have the given port as their local endpoint. Within those limits, the CE-to-CE connectivity is up to the CEs themselves 💅 In other words, the SP lets an L1VPN have a certain set of topologies (described as a port-to-port connectivity matrix), and CE-initiated signaling is used to pick one particular topology from that set ✨
For each L1VPN that has at least one port on a given PE, the PE keeps a Port Information Table (PIT) for that L1VPN 🦋 That table holds a list of <CPI, PPI> tuples for all the ports inside its L1VPN. For the local PE ports of a given L1VPN, the tuples also include the VPN-PPIs of those ports 💖
PE PE
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || Route | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+|Dissemination| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B |
| CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 |
+--------+ | | || (Backbone ) | | | | +--------+
| +------+| --------- | +----------+ |
| | | |
+--------+ | +-----+ | | +----------+ | +--------+
| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
| CE1 |--| |PIT | | | | PIT | |-| CE2 |
+--------+ | | | | | | | | +--------+
| +-----+ | | +----------+ |
+---------+ +--------------+Figure 3: Basic Mode L1VPN Service
4.1. L1VPN Port Information Tables 🧚
Figure 3 shows three VPNs, VPN-A, VPN-B, and VPN-C, each with its own PITs 💜 A PIT is made of local information as well as remote information. That means a PIT on a given PE gets filled from two sources:
- The information about the CEs' ports that are attached to the ports local to that PE.
- The information about the CEs connected to the remote PEs.
A PIT MAY be populated via provisioning or by auto-discovery procedures. With provisioning, the whole table MAY be filled in by provisioning commands, either typed at a console or sent by a management system that might have some automation. As the network grows, some kind of automation is going to be super desirable 🍓
For local information between a CE and a PE, a PE MAY use LMP to populate the <CPI, VPN-PPI> link information. That local information also needs to get passed on to the other PEs that share the same VPN 🫶 The mechanisms for this are out of scope for this document, but the information that needs to be exchanged is described in Section 4.1.1 ✨
The PIT is VPN-specific by nature 🌈 A PE is REQUIRED to maintain a PIT for each L1VPN that has member CEs attached locally to it. A PE does not need to maintain PITs for other L1VPNs. However, the full set of PITs with all L1VPN entries for multiple VPNs MAY also be available to all PEs 👑
The remote information in the context of a VPN identifier (that is, the remote CEs of this VPN) MAY also be sent to the local CE that belongs to the same VPN. Exchanging this information is outside the scope of this document 🦋
4.1.1. Local Auto-Discovery Information 🔥
The information that needs to be discovered on a PE local port is the local CPI and the VPN-PPI 🌸
This information MAY be configured. Or, if LMP is used between the CE and the PE, LMP MAY be used to exchange this information 💅
Once a CPI has been discovered, the corresponding VPN-PPI maps, in a local context, to a VPN identifier and a corresponding PPI. One way to enforce a provider-controlled VPN context is to pre-provision VPN-PPIs with a VPN identifier. Other policy mechanisms that achieve this are outside the scope of this document. That way, the relationship between a CPI and a VPN and PPI port can be set up when the port gets provisioned as belonging to the VPN ✨
4.1.2. PE Remote Auto-Discovery Information ✨
okay so this part is all about the info that auto-discovery mechanisms carry 🦋 It's what gets used to fill up a PIT dynamically. Each piece of info gives you one single <CPI, PPI> mapping. Every auto-discovery mechanism gets to decide how you send over multiple <CPI, PPI> mappings, and how you invalidate them too 💅
This info should be consistent no matter which mechanism is used to distribute it [RFC5195], [RFC5252]. Consistency is everything, bestie 🫶
Here's the format for encoding one single <PPI, CPI> tuple 🌸
+---------------------------------------+
| PPI Length (1 octet) |
+---------------------------------------+
| PPI (variable) |
+---------------------------------------+
| CPI AFI (2 octets) |
+---------------------------------------+
| CPI (length) |
+---------------------------------------+
| CPI (variable) |
+---------------------------------------+
Figure 4: Auto-Discovery InformationHere's what each field does, no cap 🎀
PPI Length:
A one-octet field whose value indicates the length of the PPI field.
PPI:
A variable-length field that contains the value of the PPI (either an address or <port index, address> tuple). Note, PPI is always encoded consistently within a provider domain, so the format of the PPI field is implicit within a given provider network. 🧚
CPI AFI:
A two-octet field whose value indicates the address family of the CPI. This value is taken from [RFC1700].
CPI Length:
A one-octet field whose value indicates the length of the CPI field.
CPI:
A variable-length field that contains the CPI value (either an address or <port index, address> tuple).
<PPI, CPI> tuples MUST also be associated with one or more globally unique identifiers that belong to a particular VPN. Literally the whole point 👑 A globally unique identifier can encode a VPN-ID, a route target, or any other globally unique identifier. These identifiers are under the control of network providers. Uniqueness within a service provider administrative domain is enough for Basic Mode operation. If you've got multiple provider networks (which is out of scope for this doc), the globally unique identifier only needs to be unique and consistent between those providers 🌈 In this document we specify one generic encoding format for the globally unique identifier that every auto-discovery mechanism shares. Each mechanism still defines its own specific method for distributing the encoding and for linking it to a <PPI, CPI> tuple ✨ The encoding of the globally unique identifier associated with the VPN looks like this:
+------------------------------------------------+
| L1VPN globally unique identifier (8 octets) |
+------------------------------------------------+
Figure 5: Auto-Discovery Globally Unique Identifier Format4.2. CE-to-CE LSP Establishment 🎀
okay now we're getting into the LSP setup 💖 In order to set up an LSP, a CE needs to know about all the other CEs in its L1VPN that it wants to connect to. A CE might already have that info through provisioning, or through some other schemes (those schemes are outside the scope of this doc, bestie).
Ports tied to a given CE-to-PE link MAY also carry other info alongside their CPI and PPI. This info describes the characteristics and constraints of the channels inside those ports 🦋 Think stuff like the encoding the channels support, the bandwidth of a channel, the total unreserved bandwidth within the port, and so on. That info could also be augmented with details about certain capabilities of the service provider network, like support for regeneration section overhead (RSOH), Data Communications Channel (DCC) transparency, arbitrary concatenation, etc. 💅 All of this is used to make sure the ports at each end of an LSP have compatible characteristics, and that there are enough unallocated resources to actually set up an LSP between those ports.
Now the spicy part 🌶️ It might happen that for a given pair of ports within an L1VPN, each CE connected to those ports tries to set up an LSP to the other CE at the same time 😭 If having a pair of LSPs between one pair of ports is seen as undesirable, the fix is to require the CE with the lower CPI value to terminate the LSP that the CE originated. This option could be controlled by configuration on the CE devices 🙈
4.3. Signaling 🧚
In L1VPN BM, a CE needs to be configured with the CPIs of other ports. Once a CE has the CPIs of the other ports in the same L1VPN (we'll call those "target ports" 🎯), the CE uses a subset of GMPLS signaling to ask the provider network to set up an LSP to a target port.
For inter-CE connectivity, the CE sends a request that contains the CPI of one of its own ports that it wants to use for the LSP, plus the CPI of the target port. When the PE attached to the originating CE gets the request, it identifies the appropriate PIT, then uses that PIT to find the PPI associated with the target port's CPI carried in the request. That PPI should be enough for the PE to set up an LSP. Eventually the request reaches the CE associated with the target CPI (the request still carries the CPI of the originating CE, so nobody gets lost 🫶). If the target CE accepts the request, the LSP is established ✨
A CE doesn't need to set up an LSP to every target port it knows about. Choosing which target ports to try to connect to is a local CE policy matter 💅
Setting up an individual connection between two corresponding CEs follows the same procedure as the one specified for GMPLS overlay [RFC4208]. Iconic 🙌
4.3.1. Signaling Procedures 💖
When an ingress CE sends an RSVP Path message to an ingress PE, the source IP address in the IP packet carrying the message is set to the appropriate CE-CC-Addr, and the destination IP address in the packet is set to the appropriate PE-CC-Addr. When the ingress PE sends the corresponding Resv message back to the ingress CE, the source IP address in the IP packet carrying that message is set to the PE-CC-Addr, and the destination IP address is set to the CE-CC-Addr.
Likewise, when an egress PE sends an RSVP Path message to an egress CE, the source IP address in the IP packet carrying the message is set to the appropriate PE-CC-Addr, and the destination IP address in the packet is set to the appropriate CE-CC-Addr. When the egress CE sends the corresponding Resv message back to the egress PE, the source IP address in the IP packet carrying that message is set to the CE-CC-Addr, and the destination IP address is set to the PE-CC-Addr.
CE-CC-Addr and PE-CC-Addr are used for more than just the IP addresses in the IP packets that carry RSVP messages between CE and PE. They're also used in the Next/Previous Hop Address field of the IF_ID RSVP_Hop Object carried between CEs and PEs 🎀
If the link between CE and PE is a numbered non-bundled link, the CPI and VPN-PPI of that link are used for the Type 1 or 2 TLVs of the IF_ID RSVP_Hop Object carried between the CE and PE. If the link between CE and PE is an unnumbered non-bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLV. If the link between CE and PE is a bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLVs.
More processing info for unnumbered links lives in Sections 3 ("Processing the IF_ID RSVP_HOP object") and 4.1 ("Unnumbered Forwarding Adjacencies") of RFC 3477 [RFC3477]. Go read those if you're curious 🤓
When an ingress CE originates a Path message to set up an LSP from one of its ports to a particular target port, the CE puts its port's CPI in the Sender Template object. If the CPI of the target port is an IP address, the CE uses it in the Session object. And if the CPI of the target port is a <port index, IP address> tuple, the CE uses the IP address part of the tuple in the Session object, and the whole tuple as the Unnumbered Interface ID subobject in the Explicit Route Object (ERO) 🦋
There are two options for RSVP-TE sessions. Option one is a single RSVP-TE session end to end, where the addresses of the customer and the provider get swapped at the PE. This is called shuffling. Option two is when stitching or hierarchy is used to create two LSP sessions: one between the provider PE(s), and another end-to-end session between the CEs 💜
4.3.1.1. Shuffling Sessions 🌸
Shuffling sessions are used when you want a single LSP that starts at the CE and ends at the far-end CE. The customer addresses get shuffled into provider addresses at the ingress PE, and back into customer addresses at the egress PE, using the mapping provided by the PIT 🔥
When the Path message arrives at the ingress PE, the PE selects the PIT associated with the L1VPN, then uses that PIT to map the CPIs carried in the Session and Sender Template objects to the appropriate PPIs. Once the mapping is done, the ingress PE replaces the CPIs with those PPIs. So the Session and Sender Template objects carried in the GMPLS signaling inside the service provider network carry PPIs, not CPIs 🧚
At the egress PE, the reverse mapping happens. The PE pulls the ingress and egress PPI values out of the Sender Template and Session objects (respectively). The egress PE identifies the appropriate PIT to find the CPI associated with the PPI of the egress CE. Once that mapping is retrieved, the egress PE swaps the ingress and egress PPI values for the corresponding CPI values. So the Session and Sender Template objects in the GMPLS RSVP-TE Path message sent from the egress PE to the egress CE carry CPIs, not PPIs 🎀
Same deal here for GMPLS RSVP-TE Path messages sent from the egress PE to the CE: the source IP address (of the IP packet carrying the message) is set to the appropriate PE-CC-Addr, and the destination IP address (of that IP packet) is set to the appropriate CE-CC-Addr ✨
At this point, the CE's view is one single LSP that's point-to-point between the two CEs, with a virtual link between the PE nodes: CE-PE(-)PE-CE. Meanwhile the L1VPN PE nodes have a full, detailed view of the PE-to-PE LSP segment 👑 The PEs MAY filter the RSVP-TE signaling, meaning they can remove info about the provider topology and replace it with a view of a virtual link 🫶
This translation of addresses and session IDs is called shuffling, and it's driven by the L1VPN Port Information Tables (see Section 4). This MUST be performed for all RSVP-TE messages at the PE edges. In this case, there is one CE-to-CE session 💅
RFC>>>
4.3.1.2. Stitched or Nested Sessions 🎀
okay so stitching and nesting depend on what LSP switching types you're working with 🧚 if the CE-to-CE and PE-to-PE LSPs match in switching type and capacity, the LSP MAY be stitched together, and the procedures in [RFC5150] apply ✨ if they don't match in switching type, or they're different but still compatible in capacity, the LSPs MAY be Nested and the procedures for [RFC4206] apply 💅 both stitched and nested signaling involve setting up a PE-to-PE session that's compatible with the CE session parameters, so they get covered together 🫶
when the Path Message shows up at the ingress PE, the PE picks the PIT tied to the L1VPN 🌸 then it uses that PIT to map the CPIs carried in the Session and Sender Template objects to the right PPIs 😭 once the mapping is done, a new PE-to-PE session gets set up with parameters that work with the CE session 🔥 and once that PE-to-PE session is up, the CE signaling request gets sent on to the egress PE 💖
at the ingress PE, when stitching or nesting is in play, a PE-to-PE session has to exist 👑 there are a few ways to make that happen:
- Associating an already established PE-to-PE LSP or Forwarding Adjacency LSP (FA-LSP) to the destination that meets the requested parameters.
- Establishing a compliant PE-to-PE LSP segment.
from the CE's point of view, it's one single LSP that's point-to-point between the two CEs, with a virtual node sitting between the PEs: CE-PE(-)PE-CE 🦋 meanwhile, the L1VPN PE nodes get the full picture of the PE-to-PE LSP segment 🌈 the PEs don't need to filter the RSVP-TE signaling to strip out info about the provider topology, because the PE-to-PE signaling is never visible to the CE nodes ✨
4.3.1.3 Other Signaling 💅
so an ingress PE may receive and potentially reject a Path message that has an Explicit Route Object in it, and that can make the switched connection setup fail 🙈 however, the ingress PE may accept EROs that include a sequence of {<ingress PE (strict), egress CE CPI (loose)>} 🫶
- Path message without ERO: when an ingress PE gets a Path message from an ingress CE that has no ERO, it MUST calculate a route to the destination for the PE-to-PE LSP and put that route into an ERO before forwarding the Path message. The one exception would be if the egress core node were also adjacent to this core node. 🧚
- Path message with ERO: when an ingress PE gets a Path message from an ingress CE that has an ERO (in the form described above), the former computes a path to reach the egress PE. It then inserts this path as part of the ERO before forwarding the Path message. 🦋
in the case of shuffling, the overlay rules for notification and RRO processing are exactly the same as the User-Network Intercase (UNI) or Overlay Model [RFC4208] 💜 those rules say the Edge PE MAY remove/edit Provider Notification and RRO objects when it passes messages along to the CEs 🌸
4.4. Recovery Procedures 🛡️
Signaling:
a CE can ask for a network-protected LSP (basically, an LSP that's protected from PE-to-PE) by using the technique in [RFC4873] 🔥 dynamic identification of merge nodes is supported through the LSP Segment Recovery Flags in the Protection object (see Section 6.2 of [RFC4873]) ✨
Notification:
a Notify Request object MAY be inserted in Path or Resv messages to show the address of a CE that should be notified of an LSP failure 🎀 notifications MAY be requested in both the upstream and downstream directions:
- Upstream notification is indicated by including a Notify Request object in the matching Path message.
- Downstream notification is indicated by including a Notify Request object in the matching Resv message.
a PE that gets a message with a Notify Request object SHOULD store the Notify Node Address in the matching RSVP state block 💖 the PE SHOULD also put a Notify Request object into the outgoing Path or Resv message 🫶 the outgoing Notify Node Address MAY be updated based on local policy, which means a PE that receives this object from the CE MAY change the value of the Notify Node Address 👑
if the ingress CE puts a Notify Request object into the Path message, the ingress PE MAY swap the received 'Notify Node Address' for its own selected 'Notify Node Address', and in particular its local TE Router_ID 🦋 the Notify Request object MAY be carried in Path or Resv messages (Section 7 of [RFC3473]), and its format is defined in [RFC3473] 🌈 per Section 4.2.1 of [RFC3473], Notify Node Addresses SHALL be set to either IPv4 or IPv6 💅
including a Notify Request object is used to ask for notifications when a failure happens, but it doesn't guarantee that a Notify message will actually get generated 🙈
5. Security Considerations 🔐
okay this part is SERIOUS bestie, so pay attention 😭🔥 security for L1VPNs is covered in [RFC4847] and [RFC5253] 💜 in this document, we're talking about the security side of the control plane 🧚
linking a particular port to a particular L1VPN (or, to be more precise, to a particular PIT) is a configuration operation, and the service provider usually does it by hand as part of service provisioning 💖 because of that, it can't be changed through signaling between CE and PE 🌸 which means signaling can't be used to send L1VPN traffic to the wrong customer 👑 the operator should apply appropriate security mechanisms to the management and configuration process, and should think about data plane verification techniques to guard against accidental misconfiguration 🛡️ the customer can also run end-to-end (CE-to-CE) data plane connectivity tests over the L1VPN connection to catch misconnection 🦋 that data plane connectivity testing can be done with the Link Management Protocol (LMP) [RFC4204] ✨
it's also possible to fill in the local part of a PIT using auto-discovery through LMP 🎀 LMP MAY be secured as described in [RFC4204] 💅 signaling between CE and PE is assumed to happen over a private link (for example, in-band or in-fiber) or a private network 🫶 a private link makes the CE-to-PE connection secure at the same level as the data link described in the previous paragraphs 🌈 using a private network assumes that outside entities can't spoof or modify CE-to-PE control plane communications, and that every entity inside the private network is trusted 🙈 so, no security mechanisms are required by the protocol exchanges in this document 💜
BUT, if an operator is worried about the security of their private control plane network, they can use the authentication and integrity functions in RSVP-TE [RFC3473], or use IPsec ([RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411]) for the point-to-point signaling between PE and CE 🔥 see [MPLS-SEC] for a full discussion of the security options for the GMPLS control plane 🧚
also note that a private network (e.g., Layer 2 VPN or Layer 3 VPN) might be used to give control plane connectivity between a PE and more than one CE 🌸 in that case, it is RECOMMENDED that each L1 VPN customer have its own private network 👑 then, the security mechanisms the private network provides SHOULD be used to keep the customer-to-service-provider control plane communication secure 💖
6. References 📚
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, February 2008.6.2. Informative References
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1
Virtual Private Networks", RFC 4847, April 2007.
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007.
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based
Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-
Discovery", RFC 5252, July 2008.
[RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1
Virtual Private Network (L1VPN) Basic Mode", RFC 5253,
July 2008.
[MPLS-SEC] Fang, L., Ed., " Security Framework for MPLS and GMPLS
Networks", Work in Progress, February 2008.7. Acknowledgments 🫶
the authors would like to thank Adrian Farrel, Hamid Ould-Brahim, and Tomonori Takeda for their valuable comments 💖
Sandy Murphy, Charlie Kaufman, Pasi Eronen, Russ Housley, Tim Polk, and Ron Bonica provided input during the IESG review process 🌟
Authors' Addresses ✨
Okay bestie, here are the people who wrote this RFC 🎀 Their contact info is below, exactly as it was written 💅
Don Fedyk
Nortel Networks
600 Technology Park
Billerica, MA 01821
Phone: +1 (978) 288 3041
EMail: dwfedyk@nortel.com
Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
EMail: yakov@juniper.net
Dimitri Papadimitriou
Alcatel-Lucent
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: Dimitri.Papadimitriou@alcatel-lucent.be
Richard Rabbat
Google Inc.
1600 Amphitheatre Pky
Mountain View, CA 95054
EMail: rabbat@alum.mit.edu
Lou Berger
LabN Consulting, LLC
Phone: +1 301-468-9228
EMail: lberger@labn.netFull Copyright Statement 🦋
Copyright (C) The IETF Trust (2008) 🌸
This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth there, the authors keep all their rights 💜
This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This is the legal stuff, so it stays serious even though I'm being extra 🙈
Intellectual Property 🔥
The IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope, or on whether any license under those rights is or isn't available for implementing or using it 😭 It also doesn't say it has independently tried to find any such rights. You can find the procedures for rights in RFC documents in BCP 78 and BCP 79 📚
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission to use such proprietary rights for implementers or users of this specification can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🌈
The IETF invites any interested party to tell it about any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that information to the IETF at ietf-ipr@ietf.org 💖
📦 where this page comes from
- ietf: rfc5251 2008-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms