Supported Carrier Ethernet VCs
In a Carrier Ethernet (CE) network, data is transported across point-to-point and multipoint-to-multipoint Ethernet Virtual Connections (EVCs) and Operator Virtual Connections (OVCs) according to the attributes and definitions of the various service types—that is, E-Line, E-LAN, E-Tree, and E-Access.
Each EVC type has a port-based service and a VLAN-based service. These are differentiated by the method for service identification used at the UNIs. EVCs using all to one bundling UNIs (port-based) are referred to as ‘Private’, while EVCs using UNIs that are that are service multiplexed (VLAN-based), are referred to as ‘Virtual Private’
For E-Line, E-LAN, and E-Tree services, each EVC carries data in the form of CE service frames from UNI (User Network Interface) to UNI, where the UNI is the physical demarcation point between the responsibility of the Service Provider and the responsibility of the Subscriber. E-Access Operator Virtual Circuits (OVCs) allow service provider interconnections at the ENNI (External Network Network Interface), which is the physical demarcation point between the responsibility of two interconnecting Service Providers.
Each EVC can be configured with a rich set of attributes that include bandwidth profiles (CIR, EIR, CBS, EBS), multiple classes of service, application-oriented performance objectives, traffic management, forwarding rules, and so on.
Cisco EPN Manager supports the discovery and provisioning of the following EVC types, which are described in these topics:
– MPLS to the edge
– Single-segment pseudowire
– Ethernet access—local, G.8032
– MPLS to the edge
– Single-segment pseudowire
– VPLS/H-VPLS with redundant pseudowire
– Ethernet access—VPLS-based
Core Technology for Multipoint EVCs
The core technology for the E-LAN EVC can be either VPLS (Virtual Private LAN Services) or H-VPLS (Hierarchical VPLS). The core technology for E-TREE EVCs is H-VPLS.
- VPLS—A Layer 2 VPN technology that provides Ethernet-based multipoint-to-multipoint communication over MPLS networks. VPLS allows geographically dispersed sites to share an Ethernet broadcast domain by connecting sites through pseudowires. The network emulates a LAN switch or bridge by connecting customer LAN segments to create a single bridged Ethernet LAN.
- H-VPLS— Partitions the network into several edge domains that are interconnected using an MPLS core. The edge devices learn only of their local N-PE devices and therefore do not need large routing table support. The H-VPLS architecture provides a flexible architectural model that enables Ethernet multipoint and point-to-point Layer 2 VPN services, as well as Ethernet access to Layer3 VPN services, enabling service providers to offer multiple services across a single high-speed architecture. In E-TREE EVCs, H-VPLS together with split-horizon capabilities is used to prevent leaf to leaf communication.
E-Line refers to an Ethernet service that is based on a point-to-point EVC. There are two types of E-Line VCs:
- Ethernet Private Line (EPL), which has the following characteristics:
– Uses a point-to-point EVC between two UNIs to provide a high degree of transparency such that service frames, headers, and most Layer 2 protocols are identical at both the source and destination UNI.
– All to one bundling where all CE-VLAN IDs are bundled to one EVC. No service multiplexing.
- Ethernet Virtual Private Line (EVPL), which has the following characteristics:
– Uses a point-to-point EVC between two UNIs, but does not provide full transparency as with the EPL, that is, all Layer 2 control protocols are discarded at the UNI.
– Allows for service multiplexing, which means that more than one EVC can be supported at the UNI.
E-LAN refers to an Ethernet service that is based on a multipoint-to-multipoint EVC. There are two types of E-LAN VCs:
- Ethernet Private LAN (EP-LAN), which has the following characteristics:
– All-to-one bundling at the UNI
– Very transparent, no manipulation of CE-VLAN IDs and PCP bits
– EP-LAN multiport transparency is more complex than EPL
- Ethernet Virtual Private LAN (EVP-LAN), which has the following characteristics:
– Allows for service multiplexing and bundling
An E-Tree VC is a rooted multipoint VC that connects a number of UNIs providing sites with hub and spoke multipoint connectivity. Each UNI is designated as either root or leaf. A root UNI can communicate with any leaf UNI. A leaf UNI can communicate only with a root UNI, not with another leaf UNI.
E-Tree VCs provide the separation between UNIs required to deliver a single service instance in which different customers (each having a leaf UNI) connect to an ISP which has one or more root UNIs. Having more than one root UNI is useful for load sharing and resiliency schemes.
There are two types of E-Tree VCs:
- Ethernet Private TREE (EP-TREE), which has the following characteristics:
– Rooted multipoint, port-based.
– All-to-one bundling at the UNI.
– Simpler than typical hub and spoke configuration using multiple EPLs. Hub function is performed by the root UNI.
– Provides CE-VLAN tag preservation and tunneling of key Layer 2 Control Protocols.
– Supports CE-VLAN CoS preservation.
- Ethernet Virtual Private TREE (EVP-TREE), which has the following characteristics:
– Rooted multipoint, VLAN-based.
– Provides an alternative to multiple EVPLs multiplexed at the hub site.
– Used in cases where one or more of the subscriber’s UNIs also supports other services, e.g., EVPL or EVP-LAN.
An Ethernet Access service allows a service provider to construct an Operator Virtual Connection (OVC) between two customer sites where one of the sites is located outside of the service provider’s own network. In such cases a service provider uses an E-Access service offered by a local wholesale access provider to reach the out-of-franchise UNI. The service provider connects to the E-Access service at an ENNI, and traffic is forwarded between the ENNI and the out-of-franchise UNI across an Operator Virtual Connection (OVC).
E-Access definitions include attributes related to the external interfaces, in this case, the ENNI and the UNI, as well as attributes related to the virtual Ethernet connection associating these external interfaces. E-Access services use a point-to-point OVC to associate one OVC endpoint at an ENNI and one OVC endpoint at a UNI.
There are two types of E-Access VCs:
- Access EPL, which has the following characteristics:
– Private or port-based
– One OVC per UNI
– All CE-VLAN IDs are mapped to the OVC
- Access EVPL, which has the following characteristics:
– Can be multiple OVCs per UNI
– Multiple but not all CE-VLAN IDs are bundled to one OVC
Supported Network Structure for Provisioning EVCs
Cisco EPN Manager can provision EVCs over a mix of access networks. The endpoints can be configured directly on an MPLS router, an Ethernet Access switch, or an nV satellite attached to a Cisco ASR 9000 router. The EVCs may have endpoints in different Ethernet Access networks, in the same network, or on the same device. Cisco EPN Manager will configure as much as is needed to create the connectivity.
EVCs can be provisioned over the following networks:
- MPLS Domain—Cisco EPN Manager assumes that the managed network contains a single MPLS domain. Any router can communicate with any other router via a targeted LDP session. This enables the implementation of a point-to-point service between two routers with a single-segment pseudowire.
- Ethernet Access Network—Cisco EPN Manager supports EVC provisioning over Ethernet Access networks attached to a central MPLS domain. The networks are discovered by the system. EVCs can be provisioned over a G.8032 access ring or over ICCP-SM links. The access network can be:
– A G.8032 ring. This should include a router to enable the creation of EVCs that cross the MPLS domain.
– A G.8032 open ring, which means a sequence of links.
- Cisco ASR 9000 nV Satellite Topology—Cisco EPN Manager can configure EVCs on single-homed nV satellite devices attached to an Cisco ASR 9000 host.
To support service discovery and provisioning, Cisco EPN Manager must discover the topology in the access network. For successful discovery, the following prerequisites must be fulfilled:
- For ICCP-SM, LAG must be configured with LACP.
- For G.8032, CDP must be configured on the ring ports.
Supported Optical Circuits
A circuit represents an end-to-end connection between two or more connection termination points (CTPs). A circuit consists of an alternating series of cross-connections and link connections. In its simplest form, a circuit consists of a single cross-connection (if the circuit is defined between two CTPs on the same NE). A circuit can be bidirectional or unidirectional, point-to-point or point-to-multipoint, and protected or unprotected.
Cisco EPN Manager supports the provisioning of Dense Wavelength Division Multiplexing (DWDM) optical channel (OCH) circuit types and Optical Transport Network (OTN) circuit types. The DWDM optical technology is used to increase bandwidth over existing fiber optic backbones. It combines and transmits multiple signals simultaneously at different wavelengths on the same fiber. In effect, one fiber is transformed into multiple virtual fibers.
Cisco EPN Manager supports the following optical circuits types:
– Optical Channel Network Connection (OCHNC)
– Optical Channel Client Connection (OCHCC)
– Optical Channel (OCH) Trail
– Optical Channel Data Unit User-to-Network Interface (ODU UNI)
– Optical Channel Data Unit (ODU) Tunnel
Dense Wavelength Division Multiplexing (DWDM) Optical Channel (OCH) Circuit
The following topics describe the different optical channel circuit types.
Optical Channel Network Connection (OCHNC)
OCHNC circuits establish connectivity between two optical nodes on a specified C-band wavelength. The connection is made through the ports present on the wavelength selective switches, multiplexers, demultiplexer, and add/drop cards. In an OCHNC circuit, the wavelength from a source OCH port ingresses to a DWDM system and then egresses from the DWDM system to the destination OCH port.
Optical Channel Client Connection (OCHCC)
OCHCC circuits extend the OCHNC to create an optical connection from the source client port to the destination client port of the TXP/MXP cards. An OCHCC circuit represents the actual end-to-end client service passing through the DWDM system. Each OCHCC circuit is associated to a pair of client or trunk ports on the transponder (TXP), muxponder (MXP), GE_XP (in layer-1 DWDM mode), 10GE_XP (in layer-1 DWDM mode), or ITU-T line card. The OCHCCs can manage splitter protection as a single protected circuit. However, for the Y-Cable protection, two OCHCC circuits and two protection groups are required.
Optical Channel (OCH) Trail
OCH trail circuits transport the OCHCCs. The OCH trail circuit creates an optical connection from the source trunk port to the destination trunk port of the Transponder (TXP), Muxponder (MXP), GE_XP, 10GE_XP, or ITU-T line card. The OCH trail represents the common connection between the two cards, over which all the client OCHCC circuits, SVLAN circuits or STS circuits are carried. Once an OCHCC is created, a corresponding OCH Trail is automatically created. If the OCHCC is created between two TXP, MXP, GE_XP, or 10GE_XP cards, two circuits are created in the CTC. These are:
- One OCHCC (at client port endpoints)
- One OCH trail (at trunk port endpoints)
If the OCHCC is created between two TXPP or two MXPP cards, three circuits are created in the CTC. These are:
- One OCHCC (at client port endpoints)
- Two OCH Trails (at trunk port endpoints). One for the working and other for the protect trunk.
Optical Transport Network (OTN) Circuit
OTN specifies a digital wrapper, which is a method of encapsulating an existing frame of data, regardless of the native protocol, to create an optical data unit (ODU), similar to that used in SDH/SONET. OTN provides the network management functionality of SDH/SONET, but on a wavelength basis. A digital wrapper, however, is flexible in terms of frame size and allows multiple existing frames of data to be wrapped together into a single entity that can be more efficiently managed through a lesser amount of overhead in a multi-wavelength system.
The OTN specification includes framing conventions, non-intrusive performance monitoring, error correction (FEC), rate adaption, multiplexing mechanisms, ring protection, and network restoration mechanisms operating on a wavelength basis.
A key element of a digital wrapper is the forward error correction (FEC) mechanism that provides performance gains for improved margins and extended optical reach.
The OTN architecture is compliant to ITU-T G.872. An OTN circuit can be established statically or dynamically between ingress and egress nodes using Resource Reservation Protocol (RSVP) signaling. An OTN circuit is established and maintained as a label switched path (LSP) between the ingress and egress Label Switched Routers (LSRs) switched through transit LSRs. An LSP can be established as a soft permanent connection (SPC) when the request comes from the user interface.
Following are the two types of OTN circuits:
Optical Channel Data Unit User-to-Network Interface (ODU UNI)
ODU is the transport container defined to carry client signals from network ingress to egress. The ODU provides a payload area for client data along with performance monitoring and fault management. The payload area of an ODU may contain a single non-OTN signal as a client or may contain multiple lower rate ODUs as clients. An ODU UNI circuit represents the actual end-to-end client service passing through the OTN architecture.
Open Ended ODU UNI
In an open-ended ODU UNI circuit, one or both end points may be connected to ODU subcontrollers, instead of client payload controllers.
Cisco EPN Manager supports three types of open-ended ODU UNIs:
- Only the source interface is an ODU subcontroller
- Only the destination interface is an ODU subcontroller
- Both source and destination interfaces are ODU subcontrollers
To create an open-ended ODU UNI circuit, you must configure ODU subcontrollers on devices before adding the devices to Cisco EPN Manager. Use the controller oduk command to configure ODU subcontrollers on devices.
Example: Configure an ODU subcontroller on a Cisco NCS 4000 Device
In this example, two ODU0 subcontrollers are configured to an ODU1 controller.
RP/0/RP0:router(config)# controller ODU10/1/0/1
RP/0/RP0:router(config-odu1)# tsg 1.25G
RP/0/RP0:router(config-odu1)# ODU0 tpn 1 ts 1
RP/0/RP0:router(config-odu1)# ODU0 tpn 2 ts 2
To verify that the ODU subcontrollers are configured correctly on the device:
RP/0/RP0:router#sh controllers ODU0 ?
0/1/0/0 ODU0 Interface Instance
0/1/0/1/10 ODU0 Interface Instance
0/1/0/1/20 ODU0 Interface Instance
R/S/I/P Forward interface in Rack/Slot/Instance/Port format
After configuring the ODU subcontrollers on the device, you must add the device to Cisco EPN Manager. You can then verify that the ODU0 0/1/0/1/10 and ODU0 0/1/0/1/20 subcontrollers are available in the inventory.
Optical Channel Data Unit (ODU) Tunnel
ODU tunnel circuits transport the ODU UNIs. The ODU tunnel represents the common connection between two Cisco NCS 4000 series devices that are connected with Traffic Engineering (TE) links. Once an ODU UNI circuit is created, a corresponding ODU tunnel is automatically created.