|
Interoperability in a Multi-TechnologyPacket Transport Network
INTRODUCTION For a number of years, three standards development organisations (1) are expanding the application scope of their technologies and architectures to make those fit the emerging Layer 2 packet transport network. The Layer 3 services network technology (IP, MPLS) specified by IETF is extended with MS-PW and VPLS connection oriented service layers and PWE3 encapsulations for many layer 1 and layer 2 client signals, the Layer 1 (SDH, OTN) transport network architecture, operation, OAM and protection switching specified in ITU-T is applied to MPLS and Ethernet technologies to make those transport grade and the Ethernet enterprise network technology (802.1Q) is extended by IEEE802.1 with additional layers and OAM to improve its scalability and management. Those developments are not finished yet. MPLS is currently being expanded with a transport network profile and Ethernet is expanded with traffic engineered connectivity. Initially, each technology will be deployed in isolated domains and networks, but eventually all those domains and networks will have to interoperate to provide world-wide packet transport services support. Interoperability is a primary requirement as such. The Metro Ethernet Network architecture of the MEF – with its Application Services, Ethernet Services and Transport layers as specified in MEF4 [1] – could be the architecture enabling such interoperability. This requires that this architecture is accepted as common architecture for the global packet transport network1 by the other standards development organisations and that those organisations complement the Ethernet Services layer specifications with Ethernet, MPLS and OTN based Transport layer specifications, develop the interworking function specifications for additional client signals into the Ethernet Services layer (e.g. ATM-IWF, FR-IWF), develop additional interworking function specifications for Ethernet services (ETH-IWF) to enhance scalability within the Ethernet Services layer and develop interworking function specifications for the interoperability of this global packet transport network with existing MPLS networks which do not include the Ethernet Services layer. This paper presents emerging Transport layer architectures and technologies, clarifies the roles of and relationship between the Ethernet Services and Application Services layers, discusses the disadvantages of a competing MPLS Services layer and explorers several interoperability cases between carriers. PACKET TRANSPORT NETWORK ARCHITECTURE The term Packet Transport Network (PTN) refers to the functionality within the Application Services, Ethernet Services and Transport layers and their InterWorking Functions (IWF), which are located between the set of User-to-Network-Interfaces (UNI) as illustrated in Figure 1. The Ethernet Services layer is an Ethernet specific implementation of the more generic Transport Services layer. A potential additional Transport Services layer could be an MPLS-TP Services layer.
Figure 1 – Packet transport network layers with Ethernet Services layer
Ethernet Services are provided in the PTN via EVC Type II connections and Application Services are provided via EVC Type I connections plus application specific interworking functions; e.g. TDM interworking functions specified in MEF8 [3]. One or more application service instances may be supported by one EVC Type I. An EVC Type II supports a single Ethernet service instance (i.e. single This gobal packet transport network may be generically referred to as Carrier Ethernet Network (CEN) as introduced in draft MEF12.1 and may consist of MPLS Transport Profile and Traffic Engineered Ethernet network domains. VLAN or Backbone Service Instance). An Ethernet bundled service is supported as an Application Service1; the IWF provides the n:1 bundling via the insertion or preservation of the appropriate 802.1Q Tags. The EVC Type I connections terminate within the PTN and are fully owned by the PTN. All the OAM Maintenance Entity Group (MEG, refer to [1],[5]) levels (NCM, TCM, LCM)1 within such EVC are owned by the PTN and the UN has EVC independent MEG levels within the Application Services layer as illustrated in the top part of Figure 2. The EVC Type II connections terminate in the User Network (UN) and ownership is shared by the PTN and UN as illustrated in Figure 2, bottom. The higher MEG Levels (typically levels 5 to 7) are allocated to the UN, while the lower MEG Levels (typically 0 to 4) are allocated to the PTN.
Figure 2 – "Applications Services" Services Model
The VP layer may deploy Ethernet VLANs (Ethernet VP), MPLS-TP LSPs (MPLS VP), or PBB-TE TESI (PBB-TE VP). The VS layer may deploy Ethernet VLANs (Ethernet VS) or MPLS-TP Section LSPs (MPLS VS). The VP signals carry EVC signal aggregates, the VS signals carry either EVC signal aggregates or VP signal aggregates and the PHY signals carry EVC signal aggregates, VP signal aggregates or one VS signal. The client/server type interworking functions (see Figure 1) between the EVC and PHY, EVC and VS, EVC and VP, VP and VS, and VP and PHY layers insert identifiers (1) to uniquely mark each frame or packet of an EVC or VP instance within the aggregate signal, insert priority and drop eligibility indications and add sufficient encapsulation to obtain client/server independence between the layers. The interworking function between the VS and PHY layers may insert priority and drop eligibility indications in each frame or packet and encapsulate those frames or packets to carry those over the PHY. Each subscriber reachable via the access multiplexer, will get a consecutive subset of its PCC-MAC addresses of which the M6 (M>N) most significant bits identify the subscriber. Forwarding within such rmp wholesale EVC will then be controlled by new subnet filtering rules which learn and register the N or M most significant bits of the MAC address instead of all 48 bits.
The connections in the PTN are traffic engineered. The PHY and VS layer connections are point-to-point connections. The VP layer connections are in majority point-to-point connections which interconnect the EVC switch/bridge equipment located at the edge of a domain. Those point-to-point VP connections may be complemented with some point-to-multipoint VP connections to support Broadcast TV services.
The EVC layer provides point-to-point (p2p), point-to-multipoint (p2mp), rooted-multipoint (rmp) and multipoint-to-multipoint (mp2mp) EVCs. Those EVCs are traffic engineered; each EVC link connection has a defined CIR and EIR, which should be enforced by means of traffic conditioning at UNI-N input ports at the edge of the PTN and for mp2mp and rmp EVCs also at NNI output ports within the PTN. Each EVC supports either an Ethernet Line, Tree or LAN service, or a non-Ethernet (e.g. TDM, ATM) Line or Tree service. Users of the PTN are governmental organisations, educational institutes, businesses, carriers and voice, data and video service providers and their subscribers. Those service providers connect at regional and/or national wholesale access points to the PTN to reach the access multiplexers and connected subscribers. The other users connect at individual access points at the edge of the network, often located in the user’s premise. An objective in a transport network is to minimize the amount of state in the network to increase the scalability and limit the complexity of the network. For the PTN this objective is partly met by layering and aggregation of EVC and VP signals as described above and by partitioning into administrative (carrier) domains and subdomains (e.g. access, metro, core) illustrated in Figure 3. EVC switching/bridging functionality is then restricted to domain edges and VP connections are domain bound. Furthermore, the scalability of the PTN is increased when high bit rate PHY links are deployed instead of multiple lower rate PHY links, and when Customer MAC addresses in rmp and mp2mp EVCs are aggregated. Aggregation of MAC addresses may be performed by means of either the insertion of an additional MAC header in the EVC Termination or the following EVC Switch/Bridge equipment, or (for the case of rmp wholesale EVCs) the translation of Customer MAC addresses into locally administered and subnetwork structured Provider Controlled Customer MAC addresses. The N(2) most significant bits of such PCC-MAC address identify an access multiplexer and the associated set of PCC-MAC addresses.
Figure 3 – PTN network architecture example with EVC Termination, EVC Switch/Bridge and VP Switch equipment
CARRIER-CARRIER ARCHITECTURES Several types of carrier-carrier relationships exist in today’s networks. 1.Carrier A may interconnect two of its subnetworks via the network of another In all cases more then one service instance and thus more then one EVC will be involved and it has advantages to pass through the network of the inter/regional carrier B with a VP or VS signal. Carrier B has to provide only a single service, while carrier A or carriers A and C can transport multiple EVCs via this single VP or VS service provided by carrier B. The inter-carrier domain B may carry a VP signal of carrier A as one of its EVC signals (Figure 4, top) when the VP signal is an Ethernet VP signal. Carrier A monitors its Ethernet VP signal using the EVP NCM MEG level (level 7). Inter-carrier B will monitor this signal via an EVC TCM MEG level (e.g. level 4). EVC and EVP are context sensitive terms; the same signal is an EVC from the viewpoint of inter-carrier B and an EVP from the viewpoint of carrier A. The inter-carrier domain B may carry an Ethernet VS signal of carrier A as one of its EVC signals (Figure 4, bottom). For this case the EVC and EVS represent the same signal; from the viewpoint of carrier A the signal is an EVS signal, from the viewpoint of the inter-carrier B it is an EVC signal. Both cases create a hierarchical PTN architecture with in total more then three layers. Nonetheless this hierarchical PTN, each carrier and inter-carrier network will only have to manage one EVC layer, one VP and one VS layer. This is a form of PTN recursion which makes the inter-carrier domain similar to the carrier domain. Note that one of the domains of carrier A may just be a network termination device that is owned by carrier A and is located behind the inter-carrier B domain. Carrier A and carrier B networks interconnect via inter-domain interfaces that are referred to as Ethernet External-NNIs (E-NNI)
Figure 4 – Carrier and Inter-Carrier layer stack examples (I)
These interconnection cases don’t change that much when carrier B interconnects the networks of different carriers A and C (see Figure 5). Carriers A and B and carriers B and C are interconnected via Ethernet E-NNIs. In addition, carriers A and C are interconnected via a Virtual E-NNI associated with the EVP and the EVCs transported inside the EVP. The service provider S will be aware of this Virtual E-NNI due to the presence of Ethernet MIP functions at the edges of carrier A and carrier C domains.
Figure 5 – Carrier and Inter-Carrier layer stack examples (II)
In the third case, illustrated in Figure 6, a carrier A provides an Ethernet service to a user X. User X is located behind the network of (regional) carrier B. Carrier B owns the network termination device to which user X is interconnected. This network termination device provides a port-based (EVS) service to user X. The EVS signal of user X is passed through the domain of carrier B as an EVC and delivered to carrier A as an EVP signal, together with other EVP signals. A dedicated EVS signal may carry this group of EVP signals over the E-NNI. Remarkable in this case is the three different roles that one Ethernet VLAN can perform: EVS for user X, EVP for carrier A and EVC for carrier B.
Figure 6 – Virtual UNI Layer stack example Example: Ten users are connected to carrier B network via Fast Ethernet interfaces. Carrier A is connected to carrier B network via a Gigabit Ethernet interface supporting a service multiplex for up to ten E-LINE services. Carrier B provides a port-based E-LINE service to the ten users and aggregates their signals before delivering those over the Gigabit Ethernet interface to carrier A. Carrier A and B interconnect via an Ethernet E-NNI while carrier B and user X interconnect via a UNI. Carrier A and user X interconnect via a Virtual UNI (V-UNI), which is invisible for carrier B.
OPTICAL BYPASS EVC aware nodes in the carrier and inter-carrier domains may be interconnected via the Layer 1 optical transport network, bypassing the VP layer switching nodes. Such “optical bypass” is efficient when the bandwidth exchange between the two EVC switching/bridging nodes exceeds a few Gbit/s. It may also offer enhanced performance in the form of reduced frame delay, frame delay variation and frame loss. Bypass of the PTN inter-carrier domain may be beneficial when two carrier domains exchange large sets of EVC signals. The carrier domains may then interconnect their VP or VS signals through the optical transport network. For both cases, ITU-T SG15 is extending its optical transport network (OTN) specifications [6]. Already specified are the capabilities for timing transparent transport of 1GE, 10GE, 40GE and 100GE 802.3 signals through the OTN. Under development is the addition of a “Packet-ODUflex”, which provides an OTN based VP connection of which the bit rate is “n x 1.244 Gbit/s”, with n = 1,2,..,80. This latter development provides a tool for further integration of the PTN and OTN towards a Packet Optical Transport Network (P-OTN).
ETHERNET VIRTUAL CONNECTIONS The EVC layer supports its services via destination-agnostic point-to-point, destination-agnostic point-to-multipoint, destination-aware rooted-multipoint and destination-aware multipoint-to-multipoint Ethernet Virtual Connections (EVCs). The former two EVC types flood the incoming frames to their output port or ports (i.e. typical connection-oriented forwarding), the latter two EVC types either selectively forward, or flood the incoming frames to a single, a subset or all of their output ports under control of the destination address inside the frames. The EVC provides the connection-oriented aspect and the flooding and filtering rules inside the EVC provide the connectionless forwarding aspect. EVCs (Figure 7, black lines) are added to the PTN after installation of EVC Termination, Figure 7 illustrates two intra-metro and two inter-metro EVCs. Intra-metro EVC A1/A2 is a point-to-point EVC in metro 1. Inter-metro connection B1/B2 is a point-to-point EVC in metro 1, metro 3 and core B. Intra-metro EVC C1/C2/C3 is a multipoint-to-multipoint EVC in metro 2. Inter-metro EVC D1/D2/D3/D4/D5 is a multipoint-to-multipoint EVC in metro 1, metro 3, metro 4 and core A. Those EVCs terminate in the EVC termination equipment at the edge of the network, are switched/bridged in the EVC switch/bridge equipment at domain boundaries and are carried by the VP and VS connections between EVC equipment. EVCs have a loop free tree type topology. Such topology may cause larger latencies in mp2mp EVCs when a core or metro must be crossed twice; e.g. from D1 to D2 in metro 1 and from D3 (metro 3) to D4 (metro 4) via metro 1. This latency is reduced when branches are added to the basic tree type EVC; e.g. between EVC switch/bridge in metro 3 and in metro 4. Split-horizon (sh) functionality must then be deployed to keep the extended mp2mp EVC topology loop free. The split-horizon functionality is supported in EVC switch/bridges via a minor enhancement of the basic forwarding and filtering rules. Any incoming frame can traditionally be forwarded to all or a subset of the ports of an EVC with the exception of the port over which the frame was received. In the split-horizon case this latter port becomes a port group; the members of such port group are the link connections in the split-horizon (e.g. sh port group 1, sh port group 2 in Figure 7).
Figure 7 – EVC examples
MULTIPLE PACKET TRANSPORT NETWORK TECHNOLOGIES The EVC layer enables the interoperability in the packet transport network. The EVC provides a common layer that is present in all domains. Each domain may complement this EVC by Ethernet, MPLS(-TP), PBB-TE, OTN, etc “Transport layer” technologies, without any impact on the end-to-end interoperability. Each carrier may choose its most preferred “transport layer” technology on a domain-by-domain basis, as illustrated in Figure 8. EVC switching/bridging nodes at the edge of two or more domain terminate the domain specific “transport layer” and connect the EVCs from one domain to another domain. The network node interface (NNI) ports facing a “transport layer” domain will provide the appropriate client/server interworking as well as the necessary VP and VS OAM functions. The assumption in Figure 8 is that all packet interfaces will be using 802.3 Ethernet interfaces. For this case an EVC can appear on such 802.3 interface untagged, single-tagged, double-tagged, triple-tagged1, double-labelled, double-labelled plus tagged2 or triple-tagged7 with additional DA/SA fields. It is still an open issue which ethertype values can and should be used for the EVC-Tag, EVP-Tag and EVS-Tag. In some networks the 802.1Q [8] C-Tag and S-Tag are reused to identify the traffic engineered EVC, EVP and/or EVS signals. Those tags have not been allocated for traffic engineered VLANs and it might be necessary to deploy a new traffic engineered VLAN Tag (TE-Tag) instead. All tags/labels carry the same three information elements (identifier, priority and drop eligible) but with different encoding and position in the frame. The 12-bit VID, 24-bit SID and 20-bit PW LBL subfields carry the unstructured EVC identifier within the three packet VP types. At the edges of metro and core domains those identifiers may be translated/swapped. The unstructured 12-bit VID and 20-bit LSP LBL as well as the structured 108-bit DA/SA/VID subfields carry the VP connection identifier within the EVS connections. In the VP switching equipment those VID and LSP LBL identifiers may be translated/swapped. VID translation, SID translation and Label swapping are deployed to support an infinite number of EVC and VP connections in the world wide PTN (in analogy to the infinite number of LOVC and HOVC connections in the world wide SDH network1).   Figure 8 – Inter operability in multi-technology packet transport network
The OAM added to the EVC, EVP, EVS and PVP signals consists of ITU-T Rec. Y.1731 OAM PDUs [5] with Ethernet or PBB-TE specific headers. The OAM added to the MVP signals is under development in IETF and one of the proposals is to reuse also the Y.1731 OAM PDUs but now with an MPLS-TP specific header [7]. This approach would unite the OAM usage in the packet transport network; all packet signals will deploy a common OAM, which is an advantage for network management and the operation of the packet transport network.
ADDITIONAL TRANSPORT SERVICES LAYER The Ethernet Services (EVC) layer is the enabling factor for a straightforward global interconnect. But such global interconnect could become an issue if a second, competing transport services layer technology is introduced into the packet transport network. The additional transport services layer technology under discussion is an MPLS Services layer (i.e. a MPLS-TP VC (MVC)). Such MVC layer would be realized via the Multi-Segment PseudoWire (MS-PW) technology. This MVC (MS-PW) layer would support point-to-point and point-to-multipoint services, which are only a subset of the services supported by the Ethernet VC (EVC) layer. Interoperability for point-to-point and point-to-multipoint services would not longer be trivial and would require interworking between p2p/p2mp EVC and MVC signals. An EVC<>MVC interworking function must convert the client encapsulation and OAM of the EVC signal into the client encapsulation and OAM of the MVC signal (and vice versa) and it may also have to convert the control plane and management plane information associated with the EVC and MVC signals. Such conversion could be trivial if MVC OAM reuses the Y.1731 OAM PDUs defined in Rec. Y.1731 [5]. Any deviation from those Y.1731 OAM PDUs will introduce additional complexity in the interworking function and will introduce additional complexity in the transport services (VC) layer termination and switching/bridging equipment which must support EVC termination and switching and Y.1731 based EVC OAM processes for its rmp and mp2mp EVCs.
INTEROPERABILITY WITH PROVIDER BRIDGE (PB) AND PROVIDER BACKBONE BRIDGE (BB) DOMAINS The EVC layer in a provider bridge domain is provided by the Service VLAN layer. The provider edge bridge (PEB) supports Ethernet Services (in the EVC layer) and Ethernet based Application Services which connect to the EVC layer via a Q-Tag inserting interworking function (Figure 8). The EVC layer in a provider backbone bridge domain is provided by the Backbone Service Instance (BSI) layer. The backbone edge bridge (BEB) supports Ethernet based Application Services which connect to the EVC layer via MAC header inserting, or Q-Tag and MAC header inserting interworking functions. The EVCs in those PB and PBB domains are not traffic engineered. Traffic engineering is possible when the PEB and BEB nodes are deployed as network termination devices that are directly connected to EVC switching/bridging nodes.
CONCLUSION MEF’s Metro/Carrier Ethernet architecture is the enabling architecture for a multi-technology world-wide packet transport network. The ubiquitous Ethernet Services (EVC) layer in this architecture and the use of Ethernet E-NNIs provides the glue between different Transport layer technologies under development in other standards development organizations. The possible addition of a second, MPLS based Services layer (MVC) to the packet transport network could introduce serious interoperability issues between Ethernet and MPLS transport profile networks for point-to-point and point-to-multipoint services. Footnotes: 1) ITU-T, IEEE 802.1 and IETF 2) This gobal packet transport network may be generically referred to as Carrier Ethernet Network (CEN) as introduced in draft MEF12.1 and may consist of MPLS Transport Profile and Traffic Engineered Ethernet network domains. 3) The Bundling service attribute is currently not modelled as an Application Service in MEF, making the definition of EVC ambiguous. In this paper the EVC represents a single ETH Flow Domain Fragment as defined in ITU-T Recommendation G.8010 [4], which is set up and monitored within the PTN.4) NCM: Network Connection Monitoring (MEG Level 7), TCM: Tandem Connection Monitoring (MEG Levels 1 to 6), LCM: Link Connection Monitoring (MEG Level 0). 5) These identifiers are transport layer technology dependent. When an Ethernet VP is used the EVC and EVP identifiers are provided by 802.1Q VLAN Tags. When an MPLS VP is used the EVC and MVP identifiers are provided by MPLS Label Stack Entry headers. When a PBB-TE VP is used the EVC and PVP identifiers are provided by an 802.1Q Service Instance Tag and 802.1Q Service VLAN Tag plus Source and Destination Addresses. 6) As an example, N could be 32 and M could be 44. Each subscriber could now have up to 16 MAC addresses, each access multiplexer can support up to 212 (~4000) subscribers and 230 (~1 billion) access multiplexers can be identified. A total of 242 (~4000 billion) subscribers can be uniquely identified. 7) The third tag is a priority-tag. 8) The final tag is a priority-tag. 9) Note that SDH provides an infinite number of connections using only 6-bit LOVC and HOVC “identifiers” (63 LOVC timeslots per VC4, 64 HOVC timeslots per STM-64). The number of bits in the EVC or VP identifiers (e.g. 12-bit for VLAN ID) should as such not be a limiting factor to build a world wide PTN.
REFERENCES [1] MEF4 (May 2004), Metro Ethernet Network Architecture Framework - Part 1: Generic Framework [2] Draft MEF 12.1 (February 2009), Carrier Ethernet Network Architecture Framework, Part 2: Ethernet Services Layer [3] MEF8 (October 2004),Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks [4] ITU-T Rec. G.8010 (2007), Architecture of Ethernet layer networks [5] ITU-T Rec. Y.1731 (2008), OAM functions and mechanisms for Ethernet based networks [6] ITU-T Rec. G.709 (2009), Interfaces for the Optical Transport Network (OTN) [7] IETF draft-bhh-mpls-tp-oam-y1731, MPLS-TP OAM based on Y.1731 [8] IEEE Std 802.1Q (2008), IEEE Standard for Local and metropolitan area networks, Virtual Bridged Local Area Networks
Set as favorite
Bookmark
Email This
Hits: 8743 Trackback(0)
Comments
(0)
You must be logged in to a comment. Please register if you do not have an account yet.
|
| Last Updated on Tuesday, 26 May 2009 20:24 |
TrackBack URI for this entry
Subscribe to this comment's feed
