Layer 1 VPN Basic Mode
Extracted elements (28)
A key design goal of L1VPN is 'single-ended provisioning': adding a new port to a given L1VPN requires configuration changes only on the PE that has that port. Another goal is that CE devices can establish/terminate LSPs without involving any configuration changes in service provider devices.
Two separate identifiers are defined at each PE port (PPI for the provider realm and VPN-PPI for the customer realm) so that service provider operations remain independent of the VPN customer's addressing realm, and the service provider addressing realm is hidden from the customer.
When two CEs concurrently attempt to establish LSPs to each other (creating a duplicate pair), the CE with the lower CPI value should terminate the LSP it originated. This optional, configurable tie-breaking rule avoids undesirable duplicate LSPs without requiring protocol negotiation.
L1VPN Basic Mode signaling between CE and PE follows the GMPLS overlay model defined in RFC 4208. The overlay rules for Notification and RRO object processing (e.g., an edge PE MAY remove or edit Provider Notification and RRO objects when passing messages to CEs) apply in the shuffling case.
A <CE, PE> link MUST be of type <X, LSC> or <Y, TDM>, where X = PSC, L2SC, or TDM and Y = PSC or L2SC. The Generalized Protocol Identifier (GPID) MUST be signaled and identical at both the head-end and tail-end CE.
A PE is REQUIRED to maintain a PIT for each L1VPN for which it has member CEs locally attached. A PE does not need to maintain PITs for other L1VPNs, though the full set of PITs for multiple VPNs MAY be available to all PEs.
All channels within a given link MUST have similar shared characteristics (e.g., switching capability, encoding, type). It is REQUIRED that for a given CE-PE pair, at least one link has at least one data-bearing channel and at least one control-bearing channel, or that there is IP reachability between CE and PE.
CPI-to-PPI and PPI-to-CPI address shuffling MUST be performed for all RSVP-TE messages at the PE edges when the shuffling session model is used.
GMPLS RSVP-TE MUST be used for signaling both within the service provider network (between PEs) and between the customer and the service provider (between CE and PE).
If the CPI is an IPv4 address (or tuple containing an IPv4 address), then the VPN-PPI MUST be an IPv4 address (or tuple) as well, since VPN-PPIs are created from the customer address space. The same constraint applies for IPv6: an IPv6 CPI requires an IPv6 VPN-PPI.
It is REQUIRED that a service provider have a single addressing realm spanning all PE devices involved in providing the L1VPN service (the service provider addressing realm). It is further REQUIRED that each L1VPN customer have its own addressing realm; customer realms MAY overlap with each other and with the service provider realm.
It is REQUIRED that the CE-PE interface be capable of initiating and processing GMPLS protocol messages per RFC 3473 and of following the procedures in RFC 4208.
Per RFC 3473 Section 4.2.1, Notify Node Addresses in Notify Request objects SHALL be set to either IPv4 or IPv6.
<PPI, CPI> tuples MUST be associated with one or more globally unique identifiers tied to a particular VPN. Uniqueness within a service provider administrative domain is sufficient for Basic Mode operation.
The CE Control Channel Address (CE-CC-Addr) and PE Control Channel Address (PE-CC-Addr) are REQUIRED to be unique within the L1VPN they belong to, but are not required to be unique across multiple L1VPNs. Control channel addresses are not shared among multiple VPNs.
When an ingress PE receives a Path message from an ingress CE that contains no ERO, it MUST calculate a route to the destination for the PE-to-PE LSP and include that route in an ERO before forwarding the Path message.
A CE requests a network-protected LSP (PE-to-PE protection) using the technique in RFC 4873. Failure notifications are requested via a Notify Request object in Path or Resv messages; a PE receiving such an object SHOULD store the Notify Node Address and SHOULD include a Notify Request in the outgoing message.
Each CE-PE link is associated with a Customer Port Identifier (CPI), unique within a given L1VPN, and a Provider Port Identifier (PPI), unique within the service provider network. A third identifier, the VPN-PPI, is assigned to each PE port and is unique within the L1VPN customer addressing realm, bridging the two realms.
Each PE maintains a Port Information Table (PIT) per L1VPN, containing <CPI, PPI> tuples for all ports within that VPN. For local PE ports the tuple also includes the VPN-PPI. The PIT may be populated via provisioning or auto-discovery procedures (e.g., LMP or BGP/OSPF-based mechanisms).
In 'shuffling' sessions, a single end-to-end LSP spans CE-to-CE; the ingress PE replaces CPIs with PPIs in Session and Sender Template objects, and the egress PE performs the reverse. The CE sees a virtual point-to-point link CE–PE(–)PE–CE and is shielded from provider topology details.
In 'stitched or nested' sessions, a separate PE-to-PE session is established when the Path message arrives at the ingress PE, either by associating an existing PE-to-PE LSP/FA-LSP or establishing a new compliant segment. The CE-to-CE and PE-to-PE sessions are distinct; provider topology is not exposed to CEs.
L1VPN Basic Mode is a port-based VPN where the basic unit of service is a GMPLS-based LSP established between a pair of CE ports within a given VPN port topology. The service provider network consists of P and PE devices; CE devices connect to PEs and initiate LSP establishment. Only point-to-point links are supported.
To establish an LSP, an ingress CE originates a Path message containing the CPI of its own port in the Sender Template and the target CPI in the Session object. The ingress PE looks up the PIT to map CPIs to PPIs before forwarding within the provider network; the egress PE reverses the mapping before delivering to the egress CE.
CE-PE signaling is assumed to traverse a private link or private network where all entities are trusted, so no mandatory protocol-level security mechanisms are required. However, operators concerned about control-plane security MAY use RSVP-TE authentication/integrity functions (RFC 3473) or IPsec (RFC 4301/4302/4835/4306) for CE-PE point-to-point signaling.
The association of a PE port with a particular L1VPN (PIT) is enforced solely through manual provisioning by the service provider and cannot be altered via CE-PE signaling. This prevents signaling from being used to deliver L1VPN traffic to the wrong customer. Operators should apply security to the management process and may use LMP data-plane connectivity tests to detect misconfiguration.
When a shared private network (L2VPN or L3VPN) provides control-plane connectivity between a PE and multiple CEs, it is RECOMMENDED that each L1VPN customer have its own such private network, and that the security mechanisms of that private network SHOULD be used to protect CE-to-SP control-plane communications.
The auto-discovery encoding for a single <PPI, CPI> tuple is: PPI Length (1 octet), PPI (variable), CPI AFI (2 octets, from RFC 1700), CPI Length (1 octet), CPI (variable). Both PPI and CPI are variable-length fields containing an address or <port index, address> tuple.
The L1VPN globally unique identifier used to associate <PPI, CPI> tuples with a specific VPN is encoded as a fixed 8-octet field. It may encode a VPN-ID, a route target, or any other globally unique identifier under control of network providers.