|
|
Inter Domain Ethernet Services
Abstract This paper describes an Inter Domain Transport architecture for automatic inter domain provisioning of MEF based Ethernet services. This architecture emphasizes the aspects of interconnection scenarios between different operators, i.e. creation of end to end services across different domains operated by different Network Operators. The architecture has been developed in the ETNA project. ETNA (Ethernet Transport Network Architecture) is an ICT-FP7 European research project (1/2008-12/2009) handled by a consortium of academy and industrial entities. The participants are British Telecom (BT), Nokia-Siemens Networks (NSN), Ben-Gurion University in Israel (BGU), Helsinki University of Technology (TKK) and Ethos Networks. The ETNA project is now in the feasibility study phase, where the developed concepts will be demonstrated in BT labs. The main motivation of ETNA was to automate inter-domain service provisioning (i.e., services based on E-Line, E-LAN and E-Tree service types) in packet-based transport networks. The ETNA project developed its requirements and framework based on MEF specifications; mainly services and external interface specifications. However, since this project is a research project full alignment with MEF Specification was not considered a goal. Inter domain Ethernet services described in this paper constitute only one of the topics covered by ETNA. This paper provides the reader with an overview of this specific topic. More details about ETNA project can be found on the ETNA website [1]. As noted above, the ETNA project developed its requirements and framework based on MEF specifications; mainly services and external interface specifications. As the work in MEF progresses, future work items in MEF may require addressing requirements for more automation of service creation, teardown and modification. In such a case, MEF may find it extremely useful to base its work in the area of service automation, on the concepts developed in the ETNA project.
Introduction Inter Domain Transport Network is an architecture that helps facilitate a Global Transport Network. The Inter Domain Transport Network is a global network comprising many domains, where each domain is operated by a different network operator. The global network will be operated by a consortium of network operators (similar to the global Internet). The Inter Domain Transport Network will support Ethernet services like L2 Virtual Private Network (VPN), wholesale backhauling, leased line, virtual private line, etc., according to the MEF service definitions[3]. The architecture of Inter Domain Transport copes with the difficulties and the challenges of Service Creation in Inter Domain scenarios and provides mechanisms to facilitate automatic Inter Domain Transport Services. A domain, in the context of this paper, is a network that has a single administrative and managerial owner and is based on a particular Packet Transport technology, i.e. MEN. When Inter Domain services involve multiple Network Operators, then commercial considerations are significant. There is also a diversity of Transport Network technologies in the market (e.g. PBB, PBB-TE, L2-MPLS, MPLS-TP) and different Network Operators use different technologies. The Inter Domain Transport Network architecture, as defined by the ETNA Project, addresses these aspects. Today inter domain services and specifically setup or modification of inter domain services, involve manual intervention which can last days or even weeks. In the proposed architecture the setup period will be reduced to minutes. In addition, Inter Domain Transport allows a customer to create his own service and monitor it.
Figure 1: Inter Domain Scenario
Figure 1 describes an Inter Domain scenario. The figure shows a P2P service spanning three domains (operated by different Network Operators); each Network Operator may use a different transport technology (e.g. L2 MPLS, MPLS-TP, PPB-TE) and be managed by an independent network management system. Definitions This section describes the basic definitions of an Inter Domain Transport Network. The definitions in this paper are ETNA architecture definitions which may have similar terms to those defined by MEF in some cases and may be different from the MEF definitions in other cases. The Customer is the consumer of a service provided by an Administrative Owner (see later). The Administrative Owner is a service provider that offers services to the customers. The Administrative Owner is responsible for composing and setup of the service, while managing all aspects of the Service, which may involve one or more Elements Owners (see below). For a given Service, the Customer contracts with an Administrative Owner to be responsible for delivering the Service bounded by the UNIs associated with the Service. An Element Owner is a network operator who participates in the delivery of a service by providing a segment (or segments) of the service, based upon the capabilities described by the corresponding Element(s). The Element Owner publishes its services with their attributes and prices by using service templates. Services are built from two types of service segments: Transit service segment, which is provided by an intermediate EO Access service segment, which is provided by an end point of an EO attached to the customer equipment. A domain is any collection of network elements within a common realm of address space, path computation and network management. Different domain may be operated by same or different network operators. (Note that a Domain, in many aspects, corresponds to MEF's MEN definitions). An inter domain Ethernet Virtual Connection (EVC) traverses a Domain Chain which is composed of a consecutive series of domains (operated by EOs) that are connected via ENNI interface and collectively support the EVC. Domain chains are composed by AOs on service request or pre-calculated in order to be prepared for a future service. The MEF ENNI is defined as a reference point representing the boundary between two Operator Networks that are operated as separate administrative domains. ENNI-N1 and ENNI-N2 are the separately administered functional components that support the ENNI interface (e.g. between domain 1 and domain 2 in Figure 1). Inter Domain Bridge (IDB) (see Figure 2), as defined in the ETNA documents, is a domain-border network element, providing the ENNI functional components and communication between the domains. The IDB interfaces are termed Connection Points in this paper. Note that the term "bridge" in this paper denotes a Network Element in general and is not necessarily an IEEE compliant bridge. Figure 2: IDB AB is an access domain network element, providing the UNI-N functional components and communication access between the customer premises Ethernet network, and the access network domain. Access Domain (see Figure 3) in this context is a domain, operated by EO, which connects customers. Figure 3: Access Bridge Templates describe services that are provided by EOs to the AOs. The templates contain the services' attributes and their prices. Templates are published by the EOs to all AOs. The AOs compose end to end services by choosing elements (i.e. segments) from EOs according to the templates. Architecture The goal of Inter Domain Transport Network architecture is to enable automatic service provisioning and handling over multiple domain network that are operated by different Network Operators. There are several technologies that are in use for transport networks e.g. L2 MPLS, MPLS-TP and PPB-TE, however, the Inter Domain Transport Network architecture is agnostic to the domains' technologies concentrating only on External Interfaces (the UNI and the ENNI). The basic requirements for the External Interfaces and the service definitions comply with the MEF definitions [2] [3] [4]. Additionally, extensions to ENNI were defined by ETNA in support of the inter domain transport network architecture. An Inter Domain Transport Network requires globally unique addresses of connection points (ENNIs) and access points (UNIs) in the Global Transport Network. These addresses are used to create the EVCs between two or more points over the Inter Domain Transport Network. IP addresses could not be used for the Global Transport Network since the IP networFollowing is an example for GUID structure:k and the Transport network are two different layers that function in parallel. The chosen transport address model, called Global Unique Identifier (GUID), is a generic scheme not related to any of the popular protocol addresses. This scheme will be assigned hierarchically according to the geographical location. Following is an example for GUID structure: Figure 4: GUID Structure The global unique fields in the address should be assigned by a global addressing body like IANA (Internet Assigned Names Authority). Establishment of a new authority for transport addresses would constitute a significant step toward automatic global transport network. The address fields that will be assigned: Country Code is globally unique and will be assigned by a global entity State Code is country unique and will be assigned by country level entities City Code is country unique and will be assigned by country level entities Domain Code is country unique and will be assigned by country level entities Network Operator Code is globally unique and will be assigned by a global entity Enumerator that identifies the specific connection/access point assigned by the Network Operator Templates contain information about the service types that are provided by the domains; the templates describe the service types, their attributes and their prices. The templates are published by the EOs to the AOs; there are several protocol options for template publishing, e.g. using a distribution protocol like IS-IS with extensions that allow templates distribution. The templates include the connection points and from that information the Service Management Systems (SMS) create the domain connectivity graph and calculate the domain chain to each of the other domains. The templates allow very flexible service creation; an EO can publish the service attributes like delay, delay variation and frame loss. Each EO may publish a number of different services between pairs of connection points (e.g. the EO can offer several options for different services like voice, data, etc., between pair of connection points). Following is an example of the basic template: Transit service template. Transit Service Template Transit Service is the basic connectivity service provided by an EO; it comprises one P2P service segment e.g. of type E-LINE, between two of the domains' ENNI endpoints. A Transit service is transparent to the actual traffic that crosses the domain. A Transit Service may provide a "tunnel" to its adjacent domains by aggregating traffic belonging to several services. Transit Service is a bidirectional service. The end to end service is composed of a concatenation of transit services. The attributes of the end to end service are calculated from the segments' attributes, e.g.: The end to end price that the AO should pay for the service is the sum of the segments prices The end to end delay is calculated from the segments delay. The end to end delay variation is calculated from the segments' delay variation The service packet loss is calculated from the segments' packet loss The template includes connectivity information (the end points of the service) and several service offerings; each offer has different attributes (e.g. delay, delay variation, etc.) and price. Transit service supports the transport of traffic within the domain that offer the service and the transport of traffic over the ENNI interface between a given domain and its two adjacent domains, the boundaries of the transit service are: the connection point of the given domain and the connection point of the next domain according the signaling direction as described in Figure 5. As shown in Figure 5, domains B and C are transit domains, each providing a segment of the service (not shown in the figure) which is associated to the other domains at the domain's end points. Figure 5: Transit service end points Template content (simple form) Note: This template describes a single CoS. Table 1: Transit Service Template The Network Planes An Inter Domain Transport Network must be supported by all the network planes: management plane (MP), control plane (CP) and data plane (DP). Each plane has been extended by new functionalities defined by ETNA in order to support Inter Domain Transport. The figure below lists the main functionalities required from MP, CP and DP. Note that the functionality of inter domain service setup was split between the planes as a result of considerations for scalability, performance and the complexity of the services (e.g. certain services have strict demand for QoS, availability etc.). Inter domain topology includes the domains and the connections between the domains. Inter domain topology views domains as "black boxes", where the internal topology of the domains is not visible outside the respective domain (see example in Figure 7) Figure 7: Inter Domain Topology The management plane is responsible for the creation of the inter domain topology view. Each AO holds an updated topology of the Inter Domain Network in a repository (can be supported directly by the OSS) with calculated Domain Chains to each of the other domains. The domain chains are a list of concatenated domains. For each defined service, there is a domain chain. The domain chains are calculated by considering all the aspects that satisfy the services requirements and additionally also commercial aspects such as prices. The process of obtaining the topology and calculating the domain chains includes: 1. Auto discovery of connected domains: each domain's SMS entity discovers its adjacent domains by exchanging auto discovery messages that are exchanged over the ENNIs. 2. Service templates publishing: every domain's SMS entity publishes its service templates (including connectivity between connection points, price, protection, QoS, etc). The templates are exchanged between the AOs and the EOs SMS entities using one of the following possible options: In-band, over the ENNI Out-of band, using an inter domain Data Communication Network (DCN) management network Neutral Exchange entity, that all the domains are connected to 3. Domain Chain Computation: Each AO's SMS calculates the best domain-chains to other domains (assuming there are a few thousands of domains and the computation is scalable), by considering typical multi-constraint metrics and Service Level Specification (SLS). Based on the domain chain, the AO builds the service price and provides a quotation to the customer. Note: The templates do not contain information about the actual available BW; as a consequence during service setup alternative domain chain may be required if one of the domains in the chain can not accept the service request. The domain chain is used in the service setup process. The service setup process is described in the section below. Service setup is triggered when a customer requests a service from the AO. The service request initiates the following process: 1. Quotation, initiation and verification: a customer approaches an AO and requests a service with specific attributes (possibly by VPN portal through the public Internet). A service request contains the GUIDs of the end points and service attributes including BW, CoS, protection etc. Optionally, the end points are associated with a unique string description which is translated to a GUID using dynamic DNS requests. 2. The AO SMS entity chooses an appropriate domain chain between the end points. 3. The service is setup by inter domain signaling messages exchanged between the domains over the ENNI interface. The AO's SMS provides the Customer Premise Equipment (CPE) with the domain chain and the corresponding service template chain. The CPE initiates the signaling process over the UNI (assuming MEF UNI type 3 support) The AO's SMS provides one of the access EOs with the domain chain and the corresponding service template chain. The EO's SMS configures the UNI-N to initiate the signaling. The Customer CPE could either be configured manually or by automatic mean e.g. E-LMI [5]. The inter domain signaling is initiated after the AO composes the domain chain for the requested service. The following section briefly describes the service creation process. Note: In this example Intra Domain connections are setup by signaling, however they can be alternatively setup by management systems. Figure 8: Service Signaling Model In the UNI-C driven model, the AO provides CPE1 with the domain chain, as shown in Figure 1.
Figure 9: Option 1 - CPE1 initiates the signaling In the UNI-N driven model, the AO provides EO1 with the domain chain, as shown in Figure 2.
Figure 10: Option 2 - AB1 initiates the signaling. The role and functionality of the participating entities is described below. EO1 Role In the UNI-C driven model, AB1 receives the signaling message from CPE1. In the UNI-N driven model AB1 is configured to initiate the signaling process. In both models EO1 sets up an intra domain connection between AB1 and IDB1. In the UNI-N driven model CPE1 is either configured automatically e.g. by E-LMI or manually. Inter Domain Connection (EO1-EO2 across the ENNI) IDB1 signals IDB2 with a signaling message that contains the service ID, the domain chain, the service template chain, and the service attributes. EO2's policy manager identifies the AO (which will pay for the service), the service requirement according to the template ID and the BW, and decides whether to accept or reject the service. EO2 Role Intra domain connection is set up between IDB2 and IDB3. IDB2 communicates with IDB3 to continue the signaling toward the next domain. Inter domain IDB3-IDB4 (ENNI) IDB3 used ENNI signaling to approach IDB4; the signaling message contains the service ID, the domain chain, the template chain, and the required BW. IDB4 approaches the policy management, which identifies the AO according to the service ID and the service requirement according to the template and the BW, and decides whether accept or request the service. EO3 Intra domain connection is set up between IDB4 and AB2 by intra domain signaling. ENNI Frame FormatETNA proposed some extensions to the MEF ENNI frame format in order to facilitate automatic Inter Domain Transport and enhance scalability. Currently, the MEF ENNI specifies that the Ethernet frames exchanged at the ENNI be encapsulated by S-tags according to the IEEE 802.1ad Provider Bridge specification [5]. The Provider Bridge specification defines double tag frame format where the C-Tag is the original customer VLAN and the S-Tag is the provider VLAN. According to this definition, S-Tag designates the service over the ENNI. The maximum capacity of the S-Tag is 4K services which is not sufficiently scalable for many Inter Domain scenarios. The situation is even worse in the case of transit domain(s) where services from many domains can be aggregated over a single ENNI interface. ETNA proposed using the IEEE 802.1ah Provider Backbone Bridge [6] frame format for the ENNI. IEEE 802.1ah defines a new MAC header which encapsulates the Subscriber Service Frame. Figure 10 is an example of an ENNI frame format used in ETNA: Figure 11: ETNA ENNI Header format
ETNA ENNI control protocol (ENCP)ENCP is a CP proposed by ETNA. It has a significant role in automating the creation, deletion and modification of services in the Inter Domain Transport Network. Automating the creation, deletion and modification of services in the Inter Domain Transport Network requires protocols to exchange messages between participating domains over the ENNI. The messages are:
Like all Ethernet protocols, ENCP messages use an untagged MAC frame format with a well-known multicast group address for the MAC DA. The SA is the MAC address of the transmitting IDB. ENCP is a reliable protocol that uses acknowledgement messages to ensure delivery. RestorationIn the current phase, ETNA only defined support for protection. General Restoration models are left For Further Study. There are two categories of protection in Inter Domain Transport: service protection and network protection. Service protection ensures service delivery end to end. It is based on service level monitoring and fault detection. Network protection ensures that the network infrastructure (links and nodes) continues functioning in the events of failures or damages to elements in the network. Network level protection is required in any transport network since network failures may affect large number of services, while service level protection is required for premium and mission-critical services only. It is most often the case that customers pay extra for service protection. Service ProtectionA service is protected end to end, i.e. from access point (UNI) to access point (UNI). End to End Service Protection Model In end to end service protection, the AO establishes two disjoined EVCs between the two access points (APs) of the service (see Figure 8). Each path should be created separately. Failure detection is done by using OAM messages according to IEEE 802.1ag [8]. The OAM messages are generated and processed by the APs. The main attributes of end to end service protection are:
Service Protection TypesThe ETNA project has only defined protection solution for E-Line service types. There are two types of protection that are relevant for an inter domain E-Line service. Both are based on creation of 2 disjoint EVCs spanning between source and destination UNIs. The protection options listed below are specified in the service template:
Figure 12: End to end service protection Segment Service Protection (Future option) Segment service protection is an alternative method to end to end service protection. In segment service protection the service is built from protected segments, each segment is composed of active and standby paths (see Figure 12).
Figure 13: Segment protection In the segment service protection method the AO chooses protected service segments (the protection option is specified in the service template). Each EO is responsible for the protection of its own segment. The IDBs in this option are not protected and the ENNI links are protected by ENNI protection. Failure detection is based on OAM:
If the AO could not find an end to end path that is composed of protected segments (e.g. if some EOs do not offer protected services) then the alternative end to end service protection can be used. The main attributes of segment service protection are:
ENNI ProtectionENNI protection is link level protection; it allows the ENNI to continue functioning in the event of an ENNI link failure. ENNI protection is based on the MEF definitions and it protects against the following scenarios:
ETNA and the MEF: Opportunities and GapsThe ETNA Project specified architecture for Inter Domain Transport Network which enables Network Operators to offer automatic, on demand, global Ethernet services. The ETNA project developed its requirements and framework in based on MEF specifications; mainly services and external interface specifications. The current phase of the ETNA project is focused on MEF E-Line service types. The architecture allows extending the support for E-LAN and E-Tree service types. The ETNA architecture needed to extend the current MEF architecture to support gaps in its architecture in the following areas:
The extension to the MEF UNI in support of signaling was designed to follow the UNI Type 3 model, which allows the customer to request, signal and negotiate EVCs and their associated service attributes, with the Network. In the same manner, signaling over ENNI allows the different domains to signal and negotiate OVCs and their associated service attributes. Note that further work may be needed to extend the NID definition, beyond the current MEF definitions, in support of ETNA's Inter Domain Transport Network architecture.
SummaryThe architecture of Inter Domain Transport Network defined by ETNA enables service providers to offer automatic, on demand Ethernet services. The different domains that constitute the Inter Domain Transport Network can utilize different transport technologies such as MPLS-TP, PBB, PBB-TE, etc., but the external domains' interfaces are based on MEF UNI and ENNI definitions. ETNA architecture required enhancements to the ENNI frame format and signaling capabilities. Future work items in MEF may require addressing requirements for more automation of service creation, teardown and modification. In such a case, MEF may find it extremely useful to base its work in the area of service automation, on the concepts developed in the ETNA project. In addition a complete alignment between ETNA and the MEF definitions should be done.
References[1] http://www.ict-etna.eu/ [2] MEF 2 Requirements and Framework for Ethernet Service Protection in Metro Ethernet Networks [3] MEF 6.1 Metro Ethernet Services Definitions Phase 2 [4] MEF 11 User Network Interface (UNI) Requirements and Framework [5] MEF 16 Ethernet Local Management Interface (E-LMI) [6] MEF ENNI Base Draft (in Letter Ballot) [7] IEEE802.1ad - Provider Bridges [8] IEEE802.1ah - Provider Backbone Bridges (PBB) [9] IEEE802.1ag - Connectivity Fault Management
|
