Junos Space Layer 2 Services Overview

Junos Space Connectivity Services Director application enables you to provision the following types of services:

• E-Line services across networks that use LDP or BGP for signaling in the network core. These services use directed pseudowire virtual circuits across the network to establish point-to-point virtual private networks (VPNs). The provisioner must specify the addresses of the ingress and egress routers of the virtual circuits.

• Multipoint services across networks that use LDP or BGP signaling in the network core. The Connectivity Services Director application supports multipoint-to-multipoint (full mesh) services and point-to-multipoint (hub and spoke) services.

For details about Juniper Networks Layer 2 technologies, see the Junos OS VPNs Configuration Guide.

E-Line services and multipoint services support the following interface types:

• Port-to-port—All traffic is transported across the network.

• 802.1Q (dot1.q)—Supports 802.1Q VLAN-tagged network traffic in an E-Line or multipoint Ethernet service. Network traffic is constrained using VLAN IDs.

• Q-in-Q—Supports double-tagged traffic in an E-Line or multipoint Ethernet service.

• Asymmetric tag depth—Allows port-based, 802.1Q and Q-in-Q interfaces for UNIs to coexist in a service.

• ATM—Supports the transmission of ATM cells through point-to-point connections in an ATM network.

• TDM—Supports configuring SAToP or CESoPSN physical encapsulation of packets for transmission over the TDM interface.

Table 1 provides a guide to selecting the appropriate type of Layer 2 service for a specific customer need.

Juniper Networks refers to this kind of connection as a Layer 2 circuit. For details about Layer 2 circuits, see the Junos OS VPNs Configuration Guide.

The Connectivity Services Director application enables you to provision a range of services from the following service families for your enterprise customers:

• E-Line Services

• E-LAN Services

E-Line Services

E-Line services provide transport and encapsulation of Layer 2 Ethernet circuits between two endpoints. To provision an E-Line service, the provisioner must select the network provider-edge (N-PE) routers that will be the service endpoints and configure the user-network interfaces (UNIs) at those endpoints. The Junos Space software automates the end-to-end provisioning of the pseudowire by establishing a virtual circuit between the N-PE routers using a unique virtual circuit ID (VC ID).

The IETF refers to these connections in RFC 4905, Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks as emulated virtual circuits, and in RFC 4447, Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) as pseudowire emulation (see IETF RFC 4447).

The Metro Ethernet Forum (MEF) refers to these connections as E-Line services. See Metro Ethernet Services – A Technical Overview by Ralph Santitoro.

The Junos Space software enables you to provision the following E-Line service options for your enterprise customers:

Port-to-Port Service

A port-to-port service transports all traffic on a port on a provider edge (N-PE) router across the network to a port of another N-PE router. enterprise customers needs to purchase only a single physical port for all their traffic. However, a single port might cost more than the bandwidth for a single VLAN or selected range of VLANs.

The service provider needs no knowledge of the enterprise customer’s VLAN structure, because all the customer’s traffic is transported.

Figure 1 shows an example in which a port-to-port connection transports all VLAN traffic for an enterprise customer from customer site A to customer site B across the network.

Figure 1: E-Line LDP Connection Transports Traffic

Single VLAN Service Using 802.1Q Interfaces

802.1Q services transport VLAN traffic from one site to another across the network. The selected payload is a single VLAN, so the enterprise customer needs to purchase only the bandwidth necessary to transport that VLAN. To implement this type of service, the service provider must exchange VLAN information with the enterprise customer.

Consider the example shown in Figure 2. VLAN 100 might be used for payroll and spans sites A and B. VLAN 200 is used by engineering and spans sites A and C. Payroll and engineering are securely separated by provisioining separate point-to-point connections for each VLAN, each on a separate VCID. Service multiplexing at customer site A allows multiple virtual circuits to share the same port, yet provide secure connections to separate sites.

Figure 2: E-Line Ethernet Services with 802.1Q Interfaces

All Traffic Service Using Q-in-Q Interface

This type of E-Line (LDP) service uses Q-in-Q interfaces and transports all customer traffic from one site to another across the network. The Q-in-Q interface adds a service provider tag to the frame, which isolates the enterprise customer’s VLAN tags. The service provider does not need knowledge of the customer’s VLAN structure because all traffic is transported to the destination site.

Range of VLANs Service with Q-in-Q Interfaces

This type of E-Line (LDP) service uses Q-in-Q interfaces and carries a range of VLANs across the network. The service provider must establish with the enterprise customer which VLANs are to be transported. The service provider allocates a service provider VLAN ID as a second tag to the selected VLAN ID range, which isolates the traffic on selected VLANs from other traffic.

Figure 3 shows an example in which an enterprise customer has six VLANs with VLAN IDs 100, 200, 300, 400, 500, and 600. The service is provisioned to carry only VLANs 100, 200, and 300 by tagging them with the service provider VLAN ID of 2000. VLANs 400, 500, and 600 do not cross the network.

Figure 3: E-Line Service with Q-in-Q Interfaces for Range of VLANs.

You can use separate service VLAN IDs to segregate traffic into secure groups of VLAN IDs. For example, VLANs 100, 200, and 300 might all be part of an enterprise’s engineering organization, while VLANs 400, 500, and 600 might exchange information with suppliers. In this example, VLANs 100, 200, and 300 can be double-tagged with service VLAN ID 2000 and get transported only to the remote engineering site, while VLANs 400, 500, and 600 might be tagged with the service VLAN ID of 2001 and get transported only to the supplier’s site along a separate pseudowire, as shown in Figure 4.

Figure 4: E-Line Service with Q-in-Q Interfaces for Range of VLANs on Separate Service Provider VLANs

E-LAN Services

The Connectivity Services Director application supports E-LAN service, which in turn provides multipoint-to-multipoint services and point-to-multipoint services.

The Metro Ethernet Forum (MEF) refers to these connections as E-LAN services. See Metro Ethernet Services – A Technical Overview by Ralph Santitoro.

Figure 5 shows an example of a multipoint service connecting four customer sites.

Figure 5: Multipoint-to-Multipoint E-LAN Service—Full Mesh

This full mesh design enables direct communication among all PE routers in the service. This topology is efficient for services in which all sites need to communicate with all other sites.

Figure 6 shows a point-to-multipoint service with a single hub. The service provides connectivity between the hub router (PE1) and each of the spokes (PE2, PE3, and PE4), but no connectivity exists among the spokes.

Figure 6: Point-to-Multipoint E-LAN Service with Single Hub

This kind of topology is effective for services in which one site needs to communicate with all other sites, but communication among spokes is not required. For example, the hub site might house corporate headquarters, while each of the spoke sites is a region.

Figure 7 shows a point-to-multipoint service with two hubs. In this case, all spokes connect to both hubs.

Figure 7: Point-to-Multipoint E-LAN Service with Multiple Hubs

Typical use for dual hub routers is to provide redundancy in case of failure. For example, a data center might be duplicated at customer sites A and B, requiring access to both sites from each spoke for effective redundancy.

For all E-LAN topologies, route targets and route distinguishers designate the multipoint connectivity among the participating endpoints.

Service Autodiscovery

BGP uses autodiscovery to establish connectivity among the N-PE routers quickly and efficiently. Figure 8 shows an example.

Figure 8: Autodiscovery of Service Connectivity

In this example, device N-PE-1 is the first to be added to the service. It exports route target 100 and imports route target 100. When N-PE-2 is added to the service, it also exports and imports route target 100. The Junos OS on the device automatically makes the association and creates the connectivity path between the two devices. Similarly, when you add a third device to the service, so long as it exports/imports the same route targets as the N-PE devices in the existing service, the new device is added to the service and connectivity with both existing N-PE devices is established automatically.

For a point-to-multipoint service, route target/route distinguisher pairs have different values for import and export. These values for import and export are the same for all spokes, but reversed for the hub, thereby enabling communication between each spoke and the hub, but not among spokes. Figure 9 shows an example. In this case, device N-PE-1 (the hub router) exports route target:route distinguisher pair 100:6 and imports 100:5. Each spoke imports 100:6 and exports 100:5 enabling communication with the hub, but not with each other.

Figure 9: Autodiscovery in a Point-to-Multipoint Service

VPLS and Normalization

Similar to E-Line services, the UNIs of E-LAN services can be port-to-port, 802.1Q, Q-in-Q, or asymmetric tag depth. The type of VLAN mapping—or normalization—is specified in the service definition. VLAN normalization applies only to MX Series devices.

Normalization supports automatic mapping of VLANs. Normalization performs operations on VLAN tags to achieve the desired translation. The Connectivity Services Director application supports the following forms of VLAN normalization:

• Normalize to VLAN all—The customer VLAN ID is preserved across the network. That is, the broadcast domain includes the interfaces that have the same VLAN ID across the E-LAN service. For double-tagged packets (Q-in-Q interfaces), a pop operation at ingress strips the service VLAN ID from the packet. A corresponding push operation at egress inserts the service VLAN ID known at the local site. Hence, the service VLAN ID at egress does not have to match the service VLAN ID at ingress.

  For single-tagged packets (802.1Q interfaces), “Normalize to VLAN all” has no effect, because the packet has no service VLAN ID to pop or push.

• Normalize to VLAN none—The customer VLAN ID is not preserved across the network. The broadcast domain includes all VLANs at any site provisioned in the service. For single-tagged packets (802.1Q interfaces), a pop operation at ingress removes the customer VLAN ID from the packet. A corresponding push operation at egress adds a local customer VLAN ID.

  For double-tagged packets (Q-in-Q interfaces), both customer VLAN ID and service VLAN ID are popped from the packet at ingress and pushed at egress.

• Normalize to Dot1q tag—The VLAN tag is preserved across the network. The broadcast domain includes all VLANs at any site provisioned in the service. For information about how frames are translated to provide the required VLAN tags for interfaces with different tag heights, see the section “VLAN Mapping for E-LAN Services” in Understanding VLAN Manipulation (Normalization and VLAN Mapping) on Ethernet Services.

• Normalize to QinQ tags—The inner VLAN tag and outer VLAN tag are preserved across the network. The broadcast domain includes all VLANs at any site provisioned in the service. For information about how frames are translated to provide the required VLAN tags for interfaces with different tag heights, see the section “VLAN Mapping for E-LAN Services” in Understanding VLAN Manipulation (Normalization and VLAN Mapping) on Ethernet Services.

Normalization works well with automatically assigned VLAN IDs, because the service provider does not need to specify the VLAN IDs that are popped and pushed. Without normalization, the service provider must specify explicitly the customer VLAN ID and the service VLAN ID.

• Normalization not required—If normalization is not used, then all customer VLAN IDs and all service VLAN IDs must match to be part of the same broadcast domain.