RFC 5253

Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode

📅 published July 2008, from ietf

RFC 5253: Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode 🦋

Bestie, this one is all about GMPLS and how it can power Basic Mode Layer 1 VPNs. 💅

Written by T. Takeda, Ed., from NTT. It's filed as Informational and dated July 2008. The title block doesn't list any obsoletes or updates, so it doesn't replace or change any other RFC. ✨

Status of This Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌸

Abstract 💜

Okay so this document is an applicability statement about using Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs). 🦋

L1VPNs give customers services and connectivity at Layer 1, running over Layer 1 networks. There are two modes: Basic Mode and Enhanced Mode. The big difference is that Basic Mode has no routing information exchanged between the Layer 1 network and the customer domain. This doc looks at how GMPLS protocols can meet the requirements of a Basic Mode L1VPN. 🔥

Table of Contents 🗂️

1. Introduction ....................................................3
   1.1. Terminology ................................................3
2. Basic Mode Overview .............................................3
3. Supported Network Types .........................................4
   3.1. Data Plane .................................................4
   3.2. Control Plane ..............................................4
4. Addressing ......................................................5
5. Provider Control of Its Infrastructure ..........................5
   5.1. Provisioning Model .........................................5
   5.2. PE-to-PE Segment Control ...................................6
        5.2.1. Path Computation and Establishment ..................6
        5.2.2. Resource Management .................................7
        5.2.3. Consideration of CE-to-PE Traffic Engineering
               Information .........................................8
   5.3. Connectivity Restriction ...................................8
6. Customer Control of Its L1VPN ...................................8
   6.1. Topology Control ...........................................8
   6.2. Note on Routing ............................................9
7. Scalability and Resiliency .....................................10
   7.1. Scalability ...............................................10
   7.2. Data Plane Resiliency .....................................11
   7.3. Control Plane Resiliency ..................................12
8. Security Considerations ........................................12
   8.1. Topology Confidentiality ..................................12
   8.2. External Control of the Provider Network ..................13
   8.3. Data Plane Security .......................................13
   8.4. Control Plane Security ....................................14
9. Manageability Considerations ...................................15
10. References ....................................................15
    10.1. Normative References .....................................15
    10.2. Informative References ...................................16
11. Acknowledgments ...............................................17

1. Introduction ✨

This document is an applicability statement for using GMPLS protocols and mechanisms with Basic Mode Layer 1 Virtual Private Networks (L1VPNs), as specified in [RFC4847]. 💖

L1VPN operation is split into the Basic Mode and the Enhanced Mode. Basic Mode has no exchange of routing information between the Layer 1 network and the customer domain. Enhanced Mode does feature that exchange. 🧚

The main GMPLS protocols and mechanisms for L1VPN Basic Mode are described in [RFC5251], [RFC5195], and [RFC5252], plus a few other docs referenced in here. 🌈

Heads up: the discussion stays focused on the areas where GMPLS protocols and mechanisms actually matter. 🎀

1.1. Terminology 📖

The reader is assumed to already know the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC4026], and [RFC4847]. 🤓

2. Basic Mode Overview 🌸

As described in [RFC4847], Basic Mode has no routing exchange between the Customer Edge (CE) and the Provider Edge (PE). 🙈

CE-to-CE L1VPN connections (that's the CE-to-CE VPN connection in RFC 4847) get set up by GMPLS signaling between the CE and the PE, and then across the provider network. A L1VPN connection is limited to connections between CEs that belong to the same L1VPN. 🔗

Quick note: in L1VPNs, routing operates within the provider network. PEs may also use routing to exchange information specific to the L1VPNs the provider network supports (for example, membership information). 🦋

In L1VPN Basic Mode, the provider network is completely under the provider's control. This includes the PE-to-PE segment of the CE-to-CE L1VPN connection, which the provider controls and computes (that's PE-to-PE segment control). 👑

The L1VPN itself, built from a set of CEs and the L1VPN connections the provider gives, is controlled by each customer. That means a customer can request which CEs should be connected (topology control). A customer can also outsource management of its L1VPN to a third party, including the provider itself. Between the provider and each customer, there is a confidentiality requirement. 🫶

[RFC5251], which extends [RFC4208], specifies GMPLS signaling to set up CE-to-CE L1VPN connections. 💅

[RFC5195] and [RFC5252] describe alternative ways to exchange L1VPN membership information between PEs. One is based on BGP, the other on OSPF. 🔥

3. Supported Network Types 🌈

3.1. Data Plane 💜

The provider network can be built from any type of Layer 1 switch, such as Time Division Multiplexing (TDM) switches, Optical Cross-Connects (OXCs), or Photonic Cross-Connects (PXCs). ✨

A PE may also be an Ethernet Private Line (EPL) type of device. That's a device that maps Ethernet frames onto Layer 1 connections (using Ethernet over TDM, etc.). 🍓

The provider network may use switches with a single switching granularity (for example, only VC3 switches). It may also use switches with multiple granularities (for example, VC3/VC4 switches, or VC3 switches and OXCs). 🧚

Likewise, the provider network may offer a single type of L1VPN connection (for example, VC3 connections only), or several types (for example, VC3/VC4 connections, or VC3 connections and wavelength connections). 🌸

A CE doesn't have to be able to switch at Layer 1. It must, however, be capable of receiving a Layer 1 signal and either switching it or terminating it with adaptation. 🎀

As described in [RFC4847] and [RFC5251], a CE and a PE are connected by one or more links. A CE can also connect to more than one PE, and a PE can have more than one CE connected to it. 🦋

A CE may belong to a single L1VPN or to multiple L1VPNs. A PE may support one or more L1VPNs through a single CE or through multiple CEs. 👑

3.2. Control Plane 🛠️

The provider network is controlled by GMPLS. Within the scope of this document, L1VPN Basic Mode provider networks are limited to a single AS. Multi-AS Basic Mode L1VPNs are for future study. 🔭

As described in [RFC4847] and [RFC5251], a CE and a PE need to be connected by at least one control channel. If the CE-to-PE relationship applies to more than one L1VPN, it is necessary to disambiguate the control plane messages exchanged between the CE and the PE. That way, you can tell which L1VPN each message applies to. 🕵️‍♀️

That disambiguation can be done by giving each L1VPN its own control channel. This can be a separate physical channel, a separate logical channel (such as an IP tunnel), or separate addressing. 💖

GMPLS allows any type of control channel, as long as there is IP level reachability. In the L1VPN context, how a control channel between a CE and a PE gets instantiated may differ depending on security requirements, etc. Section 8 covers this. 🔐

4. Addressing 🎀

As described in [RFC5251], L1VPN Basic Mode lets customer addressing realms overlap with each other, and also overlap with the service provider addressing realm. So a customer network may reuse addresses that the provider network uses, and may also reuse addresses from another customer network on the same provider network. This is the same as in any other VPN model. 🦋

L1VPN Basic Mode also lets CE-to-PE control channel addressing realms overlap. A CE-to-PE control channel address (the CE's address for the control channel and the PE's address for it) only has to be unique within the L1VPN that the control channel belongs to. It doesn't have to be unique across multiple L1VPNs. 🌈

Once a L1VPN connection is established, L1VPN Basic Mode does not enforce any restriction on address assignment for that L1VPN connection (treated as a link) for customer network operation, such as an IP network or MPLS network. 💜

5. Provider Control of Its Infrastructure 👑

5.1. Provisioning Model ✨

okay so bestie, [RFC5251] says that for each L1VPN with at least one customer-facing port on a given PE, the PE keeps a Port Information Table (PIT) for that L1VPN 🗂️. The PIT is basically a cheat sheet that cross-references Customer Port Indices (CPIs) with Provider Port Indices (PPIs). It holds a list of <CPI, PPI> tuples for every port in the L1VPN. On top of that, the PE keeps an identifier called the VPN-PPI for its local ports of that L1VPN, and it gets stored in the PIT alongside the <CPI, PPI> tuples 💅

so when a new CE that belongs to one or more L1VPNs gets added to a PE, the PIT entries for those L1VPNs have to be set up on the PE 🎀. Section 4 of [RFC5251] lays out the steps:

If no PIT exists for the L1VPN on the PE, the provider creates a new PIT and ties it to the VPN identifier.
The PIT (new or already there) gets updated with info about the newly added CE. The VPN-PPI, PPI, and CPI get installed in the PIT. Note that the PPI is well-known by the PE, but the CPI has to be discovered, either through manual configuration or automatically by mechanisms like the Link Management Protocol (LMP) [RFC4204]. Also, a CE-to-PE control channel needs to be configured 🔧.
The updated PIT info needs to be pushed into the PITs on the remote PE associated with the L1VPN. Manual configuration or some kind of auto-discovery mechanism can be used for this 🌸. [RFC5195] and [RFC5252] describe alternative auto-discovery mechanisms.
On top of that, remote PIT info for the L1VPN needs to be configured on this PE if the PIT was newly created. Again, that can be done manually or through auto-discovery; see [RFC5195] and [RFC5252] 🧚.

when L1VPN membership of an existing CE changes, or when a CE gets removed from a PE, you apply similar procedures to update the local and remote PITs. it's giving consistency 🫶

5.2. PE-to-PE Segment Control 🦋

in the L1VPN Basic Mode, the PE-to-PE segment of a CE-to-CE L1VPN connection is completely under the control of the provider network. the provider is literally in charge of that whole middle part 👑

5.2.1. Path Computation and Establishment 💖

a PE-to-PE segment of a CE-to-CE L1VPN connection may be established based on various policies. Those policies can be applied per L1VPN or per L1VPN connection. the provider configures the policy, possibly based on the contracts with each customer 📝

here are examples of PE-to-PE segment connection establishment policies supported in the L1VPN Basic Mode:

Policy 1: On-demand establishment, on-demand path computation
Policy 2: On-demand establishment, pre-computed path
Policy 3: Pre-establishment, pre-computed path

in each policy, the PE-to-PE path may be computed by the local PE, or by a path computation entity outside of the local PE (for example, a Path Computation Element (PCE) [RFC4655] or a management system) 🍓

in policies 2 and 3, pre-computation of paths (and pre-establishment, if applicable) can happen at the network planning phase, or just before signaling (for example, triggered by an off-line customer request) ⭐. because of pre-computation (and pre-establishment), there could be multiple PE-to-PE segments for a specific pair of PEs. so when a PE receives a Path message from a CE for an L1VPN connection, the PE needs to figure out which PE-to-PE segment to use 🙈. in those cases, the provider may want to control:

Which L1VPN uses which PE-to-PE L1VPN segment.
Which CE-to-CE L1VPN connection uses which PE-to-PE L1VPN segment.

the first one needs a mapping between the PIT and the PE-to-PE segment. the second one needs a more sophisticated mapping method, for example:

Mapping between individual PIT entries and PE-to-PE segments.
Use of a Path Key ID [CONF-SEG] supplied by the provider to the CE, and signaled by the CE as part of the L1VPN connection request.

the L1VPN Basic Mode doesn't rule out other methods, if they're applicable 🌈.

in policy 3, stitching or nesting is necessary to map the CE-to-CE L1VPN connection to a pre-established PE-to-PE segment. no way around it, bestie 😭

5.2.2. Resource Management 🎀

the provider network may run resource management based on various policies. Those policies can be applied per L1VPN or per L1VPN connection. the provider configures the policy, possibly based on the contracts with each customer 💜

for example, a provider may choose to partition the resources of the provider network for limited use by different L1VPNs or customers. that could be achieved within the scope of the Basic Mode using resource affinities [RFC3209]. but the details of per-L1VPN resource models (especially in terms of CE-to-PE routing) are considered part of the Enhanced Mode 🔥.

5.2.3. Consideration of CE-to-PE Traffic Engineering Information 🧚‍♀️

[RFC5252] and [BGP-TE] let CE-to-PE Traffic Engineering (TE) link information be injected into the provider network, and in particular be exchanged between PEs. this can help the ingress PE avoid connection setup failure due to lack of resources or incompatible switching capabilities on remote CE-to-PE TE links 🛟.

also, the L1VPN Basic Mode lets a remote CE be reached through more than one TE link connected to the same PE (single-homed), or to different PEs (dual-homed). in those cases, to make route choice easier, the ingress CE needs to start signaling by specifying the egress CE's router ID, not the egress CPI, in the Session Object and the Explicit Route Object (ERO), if present. that way it doesn't constrain the route choice within the provider network 🦄. so the CE's router ID needs to be configured in the PITs.

note that, as described in Section 7.2, considering the full feature set enabled by dual-homing (such as resiliency) is out of scope of the L1VPN Basic Mode 🙅‍♀️.

5.3. Connectivity Restriction 🚫

the L1VPN Basic Mode lets you restrict connection establishment between CEs in the same L1VPN for policy reasons (including L1VPN security). since the PIT at each PE is tied to an L1VPN, this is super easy to support 🔐. the restriction can be applied at the ingress PE or at the egress PE, depending on the restriction policy. but applying it at the egress can waste signaling effort inside the network, since L1VPN connections get pointlessly attempted 😬.

also, the L1VPN Basic Mode doesn't restrict use of any advanced admission control based on various policies ✨.

6. Customer Control of Its L1VPN 👑

6.1. Topology Control 🗺️

in the L1VPN Basic Mode, the customer controls the L1VPN connection topology. that means a customer can request setup, deletion, or modification of L1VPN connections using the signaling mechanisms specified in [RFC5251] 💅.

also, if there are multiple CE-to-PE TE links (single-homed or multi-homed), a customer can specify which CE-to-PE TE link to use for any L1VPN connection. or, the customer can let the provider choose the CE-to-PE TE link at the egress side, as described in Section 5.2.3 🎀.

6.2. Note on Routing 🧭

a CE needs to obtain the remote CPI it wants to request a connection to. in the L1VPN Basic Mode there's no routing information exchange between a CE and a PE, so there's no dynamic mechanism supported as part of the Basic Mode L1VPN service. the knowledge of remote CPIs has to be acquired in an L1VPN-specific way, perhaps through configuration or through a directory server 📚.

if an L1VPN is used by a customer to run a private IP network, the customer may want to form routing adjacencies over the CE-to-CE L1VPN connections. the L1VPN Basic Mode doesn't enforce any restriction on that, and the way the customer uses the L1VPN connections is transparent to the provider network 🌸.

if an L1VPN is used by a customer to run a private Multiprotocol Label Switching (MPLS) or GMPLS network, the customer may want to treat an L1VPN connection as a TE link. that requires a CE-to-CE control channel 🛰️. note that a Forwarding Adjacency [RFC4206] cannot be formed from the CE-to-CE L1VPN connection in the Basic Mode, because there's no routing exchange between CE and PE. the customer network and the provider network don't share a routing instance, so the customer control channel can't be carried within the provider control plane 🚧. but where the CE provides suitable adaptation (for example, where the customer network is a packet-switched MPLS or GMPLS network), the customer control channel may be in-band, and a routing adjacency may be formed between the CEs using the L1VPN connection ✅. otherwise, CE-to-CE control plane connectivity may form part of the L1VPN service the provider gives the customer, and it may be achieved within the L1VPN connection (for example, through the use of overhead bytes) or through a dedicated control channel connection or tunnel 🫧. the options are discussed further in Section 10.2 of [RFC4847] 🦋.

7. Scalability and Resiliency 📈

7.1. Scalability 💫

there are several factors that impact scalability 🌟.

Number of L1VPNs (PITs) configured on each PE

as this number goes up, the information the PE has to maintain goes up too 📦. Theoretically, the upper limit on the number of L1VPNs supported in a provider network is governed by how the ID associated with an L1VPN is allocated, and the number of PITs configured on each PE is limited by that number. however, implementations may impose arbitrary limits on the number of PITs supported by any one PE 🙃.

Number of CE-to-PE TE links for each L1VPN

as this number goes up, the information to be maintained in each PIT goes up too 📈. when auto-discovery mechanisms are used, the amount of information an auto-discovery mechanism can support may restrict this number 🧃.

note that [RFC5252] floods membership information not only among PEs, but also to all P nodes. that may lead to scalability concerns, compared to [RFC5195], which distributes membership information only among PEs. alternatively, a separate instance of the OSPF protocol can be used just between PEs for distributing membership information. in that case, Ps don't participate in flooding 🌊.

note that in the L1VPN Basic Mode, a PE only needs to obtain CE-to-PE TE link information, not customer routing information. that's quite different from how an L3VPN operates. so the scalability concern is considered to be less problematic 💖.

Number of L1VPN connections

as this number goes up, the information to be maintained on each PE/P goes up too 🌐. when stitching or nesting is used, the state to be maintained at each PE increases compared to when connectivity is achieved without stitching or nesting 🧩.

however, in a Layer 1 core, this number is always bounded by the available physical resources, because each LSP uses a separate label that's directly bound to a physical, switchable resource (timeslot, lambda, or fiber). so it can be safely assumed that the PEs/Ps can comfortably handle the number of LSPs they may be called on to switch for an L1VPN 🥹✨

7.2. Data Plane Resiliency 💖

Okay bestie, the L1VPN Basic Mode supports the following data plane recovery techniques [RFC5251] 🫶

PE-to-PE segment recovery 🦋 The CE asks for the PE-to-PE segment to be protected by including the Protection Object specified in [RFC4873] in the Path message and setting the Segment Recovery Flags. It may also name the branch and merge nodes by including a Secondary Explicit Route Object. Depending on the signaling mechanisms used within the provider network, the details of protecting the PE-to-PE segment may differ:
- If LSP stitching or LSP hierarchy is used to provision the PE-to-PE segment, then the PE-to-PE LSP may be protected using end-to-end recovery within the provider network.
- If the CE-to-CE L1VPN connection is a single end-to-end LSP (including if session shuffling is used), then the PE-to-PE LSP segment may be protected using segment protection [RFC4873].
CE-to-PE recovery and PE-to-PE recovery via link protection 🌸 The CE asks to protect the ingress and egress CE-to-PE links, as well as the links within the provider network, by including the Protection Object specified in [RFC3473] and setting the Link Flags in the Path message.
- The ingress and egress CE-to-PE link may be protected at a lower layer. Depending on the signaling mechanisms used within the provider network, the details of protecting links within the provider network may differ:
- If the PE-to-PE segment is provided as a single TE link (stitching or hierarchy) so that the provider network can perform simple PE-to-PE routing, then the TE link may offer link-level protection through the instantiation of multiple PE-to-PE LSPs.
- The PE-to-PE segment may be provisioned using only link-protected links within the core network.

Note that it is not possible to protect only the CE-to-PE portion or only the PE-to-PE portion by link protection 🙈 The reason is that the CE-to-CE signaling request asks for a certain level of link protection on all links used by the LSP. Also, it is not possible to protect the CE-to-PE portion by link recovery and the PE-to-PE portion by segment recovery at the same time. Not allowed, periodt. 💀

CE-to-CE recovery through the use of connections from one CE to diverse PEs (i.e., dual-homing) is not supported in the L1VPN Basic Mode 🚫

7.3. Control Plane Resiliency 🧚

The L1VPN Basic Mode allows use of GMPLS control plane resiliency mechanisms ✨ This includes, but is not limited to, control channel management in LMP [RFC4204] and fault handling in RSVP-TE ([RFC3473] and [RFC5063]) between a CE and a PE, as well as within the provider network.

8. Security Considerations 🔐

Security considerations are described in [RFC4847], and this section describes how these considerations are addressed in the L1VPN Basic Mode. Main character energy, we are getting into it 😭

Additional discussion of GMPLS security can be found in [GMPLS-SEC].

8.1. Topology Confidentiality 🕵️‍♀️

As specified in [RFC5251], a provider's topology confidentiality is preserved by the Basic Mode. Since there is no routing exchange between PE and CE, the customer network can gather no information about the provider network. Further, as described in Section 4 of [RFC4208], a PE may filter the information present in a Record Route Object (RRO) that is signaled from the provider network to the customer network. In addition, as described in Section 5 of [RFC4208] and Section 4.4 of [RFC5251], when a Notify message is sent to a CE, it is possible to hide the provider internal address. This is accomplished by a PE updating the Notify Node Address with its own address when the PE receives a NOTIFY_REQUEST object from the CE.

Even in the case of pre-computed and/or pre-signaled PE-to-PE segments, provider topology confidentiality may be preserved through the use of path key IDs [CONF-SEG] 🔑

The customer's topology confidentiality cannot be completely hidden from the provider network. At the least, the provider network will know about the addresses and locations of CEs. Other customer topology information will remain hidden from the provider in the Basic Mode, although care may be needed to protect the customer control channel as described in Section 8.4.

The provider network is responsible for maintaining confidentiality of topology information between customers and across L1VPNs. Since there is no distribution of routing information from PE to CE in the Basic Mode, there is no mechanism by which the provider could accidentally, or deliberately but automatically, distribute this information. Secrets stay secret, bestie. 🤫

8.2. External Control of the Provider Network 🚪

The provider network is protected from direct control from within customer networks through policy and through filtering of signaling messages.

There is a service-based policy installed at each PE that directs how a PE should react to a L1VPN connection request received from any CE. Each CE is configured at the PE (or through a policy server) for its membership of a L1VPN, and so CEs cannot dynamically bind to a PE or join a L1VPN. With this configuration comes the policy that tells the PE how to react to a L1VPN connection request (for example, whether to allow dynamic establishment of PE-to-PE connections). Thus, the provider network is protected against spurious L1VPN connection requests and can charge for all L1VPN connections according to the service agreement with the customers. Hence, the provider network is substantially protected against denial-of-service (DoS) attacks. Iconic behavior 👑

At the same time, if a Path message from a CE contains an Explicit Route Object (ERO) specifying the route within provider network, it is rejected by the PE. Thus, the customer network has no control over the resources in the provider network. No ERO takeovers allowed. 💅

8.3. Data Plane Security 🔒

As described in [RFC4847], at Layer 1, data plane information is normally assumed to be secure once connections are established, since the optical signals themselves are normally considered to be hard to intercept or modify, and it is considered difficult to insert data into an optical stream. The very use of an optical signal may be considered to provide confidentiality and integrity to the payload data. Furthermore, as indicated in [RFC4847], L1VPN connections are each dedicated to a specific L1VPN, which provides an additional element of security for the payload data ✨

Misconnection remains a security vulnerability for user data. If a L1VPN connection were to be misconnected to the wrong destination, user data would be delivered to the wrong consumers 😱 In order to protect against mis-delivery, each L1VPN connection is restricted to use only within a single L1VPN. That is, a L1VPN connection does not connect CEs that are in different L1VPNs. In order to realize this, the identity of CEs is assured as part of the service contract. And upon receipt of a request for connection setup, the provider network assures that the connection is requested between CEs belonging to the same L1VPN. This is achieved as described in Section 5.3.

Furthermore, users with greater sensitivity to the security of their payload data should apply appropriate security measures within their own network layer. For example, a customer exchanging IP traffic over a L1VPN connection may choose to use IPsec to secure that traffic (i.e., to operate IPsec on the CE-to-CE exchange of IP traffic) 🦋

8.4 Control Plane Security 🛡️

There are two aspects for control plane security.

First, the entity connected over a CE-to-PE control channel must be identified. This is done when a new CE is added as part of the service contract and the necessary control channel is established. This identification can use authentication procedures available in RSVP-TE [RFC3209]. That is, control plane entities are identified within the core protocols used for signaling, but are not authenticated unless the authentication procedures of [RFC3209] are used.

Second, it must be possible to secure communication over a CE-to-PE control channel. If a communication channel between the customer and the provider (control channel, management interface) is physically separate per customer, the communication channel could be considered as secure. However, when the communication channel is physically shared among customers, security mechanisms need to be available and should be enforced. RSVP-TE [RFC3209] provides for tamper-protection of signaling message exchanges through the optional Integrity object. IPsec tunnels can be used to carry the control plane messages to further ensure the integrity of the signaling messages.

Note that even in the case of physically separate communication channels, customers may wish to apply security mechanisms, such as IPsec, to assure higher security, and such mechanisms must be available.

Furthermore, the provider network needs mechanisms to detect DoS attacks and to protect against them reactively and proactively. In the Basic Mode, this relies on management systems. For example, management systems collect and analyze statistics on signaling requests from CEs, and protect against malicious behaviors where necessary 🚨

Lastly, it should be noted that customer control plane traffic carried over the provider network between CEs needs to be protected. Such protection is normally the responsibility of the customer network and can use the security mechanisms of the customer signaling and routing protocols (for example, RSVP-TE [RFC3209]) or may use IPsec tunnels between CEs. CE-to-CE control plane security may form part of the data plane protection where the control plane traffic is carried in-band in the L1VPN connection. Where the CE-to-CE control plane connectivity is provided as an explicit part of the L1VPN service by the provider, control plane security should form part of the service agreement between the provider and customer. Protect your control plane, it's literally the main event. 💜

9. Manageability Considerations ⚙️

Manageability considerations are described in [RFC4847]. In the L1VPN Basic Mode, we rely on management systems for various aspects of the different service functions, such as fault management, configuration and policy management, accounting management, performance management, and security management (as described in Section 8).

In order to support various management functionalities, MIB modules need to be supported. In particular, the GMPLS TE MIB (GMPLS-TE-STD-MIB) [RFC4802] can be used for GMPLS-based traffic engineering configuration and management, while the TE Link MIB (TE-LINK-STD-MIB) [RFC4220] can be used for configuration and management of TE links 🍓

10. References 📚

10.1. Normative References 📚

okay so these are the docs this one needs to be read alongside, bestie 🫶 they're the foundations, no cap

[RFC3031]    Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
             label switching Architecture", RFC 3031, January 2001.

[RFC3209]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
             V., and G. Swallow, "RSVP-TE:  Extensions to RSVP for
             LSP Tunnels", RFC 3209, December 2001.

[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.

[RFC4026]    Anderssion, L. and Madsen, T., "Provider Provisioned
             Virtual Private Network (VPN) Terminology", RFC 4026,
             March 2005.

[RFC4202]    Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
             Extensions in Support of Generalized Multi-Protocol
             Label Switching (GMPLS)", RFC 4202, 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.

[RFC4847]    Takeda, T., Ed., "Framework and Requirements for Layer 1
             Virtual Private Networks", RFC 4847, April 2007.

[RFC4873]    Berger, L., Bryskin, I., Papadimitriou, D., and A.
             Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.

[RFC5195]    Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based
             Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.

[RFC5251]    Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D.,
             Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC
             5251, July 2008.

[RFC5252]    Bryskin, I. and Berger, L., "OSPF-Based Layer 1 VPN Auto-
             Discovery", RFC 5252, July 2008.

10.2. Informative References 🌸

these ones are more like "ooh, go read this if you're curious" 👀 not required reading, just extra context that's giving depth

[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.

[RFC4220]    Dubuc, M., Nadeau, T., and J. Lang, "Traffic Engineering
             Link Management Information Base", RFC 4220, November
             2005.

[RFC4655]    Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
             Computation Element (PCE)-Based Architecture", RFC 4655,
             August 2006.

[RFC4802]    Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
             Multiprotocol Label Switching (GMPLS) Traffic
             Engineering Management Information Base", RFC 4802,
             February 2007.

[RFC5063]    Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions
             to GMPLS Resource Reservation Protocol (RSVP) Graceful
             Restart", RFC 5063, October 2007.

[BGP-TE]     Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "Traffic
             Engineering Attribute", Work in Progress, January 2008.

[CONF-SEG]   Bradford, R., Ed., Vasseur, JP., and A. Farrel,
             "Preserving Topology Confidentiality in Inter-Domain
             Path Computation Using a Key-Based Mechanism", Work in
             Progress, May 2008.

[GMPLS-SEC]  Fang, L., Ed., " Security Framework for MPLS and GMPLS
             Networks", Work in Progress, February 2008.

11. Acknowledgments 🫶

the authors wanna give a big shoutout to Ichiro Inoue for the valuable comments 💖 they also thank Marco Carugi and Takumi Ohba for helping out with the valuable comments in the early days of this doc ✨

and a thank-you to Tim Polk and Mark Townsley for their comments during IESG review 👑

Authors' Addresses 💌

here's who wrote this, plus how to reach them 📮

Tomonori Takeda (editor)
NTT Network Service Systems Laboratories, NTT Corporation
3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 7434
EMail: takeda.tomonori@lab.ntt.co.jp

Deborah Brungard
AT&T
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
Phone: +1 732 4201573
EMail: dbrungard@att.com

Adrian Farrel
Old Dog Consulting
Phone:  +44 (0) 1978 860944
EMail:  adrian@olddog.co.uk

Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa, ON K1Y 4H7 Canada
Phone: +1 (613) 765 3418
EMail: hbrahim@nortel.com

Dimitri Papadimitriou
Alcatel-Lucent
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 2408491
EMail: dimitri.papadimitriou@alcatel-lucent.be

Full Copyright Statement ⚖️

okay this part is the legal stuff, so I'm keeping it word-for-word so nothing gets lost in translation 🙈

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein 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.

Intellectual Property 🔐

so basically the IETF doesn't take a side on who owns what 🤷‍♀️ whether any patents or rights apply to this tech, or whether you can get a license for them, is a whole separate thing. if you want the rules on rights for RFC docs, they're in BCP 78 and BCP 79 📜

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license for implementers or users are all findable on the IETF online IPR repository at http://www.ietf.org/ipr 🌈

and if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard, the IETF totally wants you to tell them at ietf-ipr@ietf.org 💜

📦 where this page comes from

ietf: rfc5253 2008-07
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms