Network Convergence Over MPLS

Network Convergence over MPLS

Enrique Vázquez, Manuel Álvarez-Campana, Ana B. García

Dept. of Telematics, Technical University of Madrid, ETS Ing. Telecomunicación, Ciudad Universitaria, 28040 Madrid, Spain {enrique, mac, abgarcia}@dit.upm.es http://www.dit.upm.es

Abstract. Multiprotocol Label Switching (MPLS) is emerging as a flexible technology that can transport voice, IPv4, IPv6, layer 2 services (Frame Relay, ATM, Ethernet, etc.), and even PDH and SDH/SONET circuits over a single packet infrastructure, in a new attempt to solve the old problem of network convergence. MPLS traffic engineering, quality of service support (in combina- tion with DiffServ), and fast restoration capabilities can be used to provide each service with strict service-level agreements (SLAs) in a cost-efficient way. Sev- eral standardization and industry organizations are contributing to this goal. This article reviews current activities in the IETF, MPLS/Frame Relay Alliance, and ITU-T related to transport over MPLS, comparing their approaches, identi- fying overlaps, and open issues.

1 Introduction

About ten years ago, the Internet Engineering Task Force (IETF) and the ATM Forum specified several solutions to transport IP packets over Asynchronous Transfer Mode (ATM) networks, including Classical IP over ATM, LAN Emulation over ATM, and Multiprotocol over ATM. All of these followed a network overlay model where IP was put over ATM, and each of them retained their own control procedures. Concur- rently, several vendors proposed alternative solutions that sought a tighter integration of IP and ATM in some cases, or simply to forward packets at very high speeds based on fixed-length labels à la ATM, but without cells. For example, in IP Switching [1], promoted by Ipsilon Networks, IP packets are segmented into cells, and the ATM virtual connection identifier included in every cell header is used as the packet label. The standard ATM signaling and routing protocols are replaced by the label assignment protocols defined by IP Switching. In more general proposals, packet labeling is defined independently of the lower layers, so that labeled packets may be transported over ATM or any other technology. See for example Tag Switching, promoted by Cisco [2]. The Multiprotocol Label Switching (MPLS) architecture, standardized by the IETF in 2001 [3], follows this general approach. Packets labeled with MPLS can be encapsulated over different layer 2 protocols, including Ethernet, Point-to-Point Protocol (PPP), Frame Relay (FR), and ATM. MPLS label values may be copied to suitable fields in the layer 2 header, for example the Data Link Connection Identifier (DLCI) in Frame Relay, or the Virtual Path/Channel Identifiers (VPI/VCI) in ATM, so that labeled packets can be forwarded directly by FR or ATM switches with the appropriate control software upgrades. The initial focus on using labels to simplify packet forwarding and increase router performance quickly shifted to using labels as a powerful tool to tag selected packet flows and control the routes they follow across the network. In particular, MPLS is very flexible in terms of: − What is labeled: IP packets or other protocol data units. MPLS can transport voice and data, with or without IP. See the following sections. − How many labels are used: several labels can be applied to the same packet form- ing a label stack. Packets are classified and labeled when they enter the MPLS network. More labels may be added to the stack at convenient points inside the network. For example, if the link between two MPLS nodes A and B fails, node A may add a new label to packets in transit in order to forward them to B via an alternative path that bypasses the failure. When the packets arrive to node B this label is removed. − What is the label meaning: for example, labels may be used to determine the packet route, to indicate a class of service, as a multiplexing identifier to distin- guish several flows that follow the same route, to separate packets corresponding to different virtual private networks, etc. − The method used to assign and distribute labels in the network: label values may be configured manually by the network administrator, or may be assigned automatically in different ways, for example coupled with the normal routing procedures in the network. Alternatively, labels may be assigned by exchanging signaling mes- sages from node to node along a particular route, similarly to a connection estab- lishment in an ATM network. The chosen route may have been selected by a con- straint-based routing algorithm taking into account the capacity required to serve a particular traffic flow. The MPLS capabilities are exploited in several important applications, including the implementation of IP Virtual Private Networks (VPNs) [4], Traffic Engineering (MPLS-TE) [5], support of Differentiated Services (DiffServ) [6], DiffServ-aware Traffic Engineering (DS-TE) [7,8], and fast rerouting [9,10]. Many aspects of MPLS are still subject of research and standardization. For example, at the time of writing this paper there were over 100 Internet Drafts related to MPLS. The focus has also shifted from transporting MPLS over different layer 2 technologies to the opposite, i.e. transporting layer 2 protocols over MPLS. In particular, MPLS is well suited to implement Virtual Private LAN Services (VPLS) that extend Ethernet over the metropolitan and wide area. This article reviews the standards and implementation agreements for voice, layer 2, and layer 1 transport over MPLS produced by the IETF, the ITU-T, the MPLS/Frame Relay Alliance (MFA), and the ATM Forum. See Fig. 1. Section 2 compares the solutions proposed by ITU-T and the MFA for direct voice transport over MPLS, i.e. without encapsulating it in ATM cells or IP packets. Sec- tions 3 and 4 present the specifications for layer 2 and layer 1 transport over MPLS under development by the IETF and the MFA. ATM Forum specifications for ATM- MPLS interworking are also considered. Finally, section 5 outlines the evolution of MPLS-based applications.

Ethernet, SONET voice voice IP ATM,… SDH PDH MFA IETF PWE3 MFA

Martini AAL2 (IA5.0) VoMPLS (IA1.0) Drafts CEP AAL1 (IA4.0)

MPLS

CEP: Circuit Emulation over Packet MFA: MPLS/Frame Relay Alliance PWE3: Pseudo Wire Emulation Edge to Edge VoMPLS: Voice over MPLS

Fig. 1. Network convergence over MPLS

2 Voice Transport over MPLS

Voice packets can be transported over MPLS without the overhead associated to the typical RTP/UDP/IP encapsulation [11]. When several voice communications are transported between the same end-points, e.g. two voice gateways in Fig. 2, concate- nating voice packets from different communications before labeling and transmission helps to reduce the encapsulation overhead. In voice over IP, the RTP/UDP/IP headers may be compressed using different algorithms like IP Header Compression, Compressed RTP, Enhanced Compressed RTP, Robust Header Compression, and others defined in RFCs or Internet drafts. Concatenation may be implemented in different protocol layers. For example, Com- posite IP (CIP) and Lightweight IP Encapsulation (LIPE) concatenate voice packets above IP, while Point-to-Point Protocol Multiplexing (PPPmux) implements concatenation at layer 2.

Gateway MPLS network PSTN Voice network ISDN … LSR VoFR PSTN VoATM … Voice network Gateway Label Switching Router Label Switched Path

Fig. 2. Voice over MPLS reference architecture

In voice over MPLS, two main solutions have been proposed for concatenation. The first one, defined in the MPLS/FR Alliance (MFA) implementation agreement 1.0 [12], supports transport of multiplexed voice channels, various voice compression algorithms, silence removal and silence insertion descriptors, transfer of dialed digits, and channel associated signaling. Each concatenated voice packet is preceded by a 4- octet header that includes a channel identifier, a payload type, a counter, and a payload length field. See Fig. 3. If the payload length is not a multiple of 4 octets, up to 3 pad octets are included to make it word (32 bits) aligned. Up to 248 calls can be multiplexed within a single Label Switched Path (LSP) identified by the outer MPLS label. As an implementation option, additional inner LSPs may be created using stacked labels.

8 8 8 6 2 bits CID Channel Identifier CID PT C L P PT Payload Type C Counter VoMPLS header L Length in words (32 bits) P PAD length in octets

payload payload payload

Layer 2 1 or more MPLS labels length must be a Layer 2 overhead (4 octets each) multiple of 4 octets overhead

Fig. 3. Voice over MPLS (MPLS/Frame Relay Alliance IA 1.0)

The second solution addresses similar functions, but instead of defining a new voice encapsulation like [12], it reuses components of the ATM Adaptation Layer type 2 (AAL2), defined for transport of several variable bit rate voice and data streams multiplexed over an ATM connection. See ITU-T recommendation Y.1261 [13] and the new MFA implementation agreement 5.0 [14]. AAL2/MPLS is concep- tually similar to AAL2/ATM but replaces ATM connections with MPLS LSPs, so the ATM cell header overhead is eliminated. AAL2 may also be used over IP as dis- cussed in [15].

RTP AAL (1, 2, or 5) UDP VoMPLS AAL2 ATM IP (MFA IA 1.0) (MFA IA 5.0) MPLS

Fig. 4. Protocol stacks for voice transport over MPLS

3 Layer 2 Transport over MPLS

The transport of voice over AAL/ATM/MPLS shown on the left column in Fig. 4 is a particular example of transport of ATM cells, containing voice or any other type of information, over an MPLS network. The ATM Forum specifications for ATM- MPLS network interworking [16,17] define procedures to send a single ATM cell, a group of cells, or an AAL5 protocol data unit (PDU) encapsulated in a MPLS frame. Long AAL5 PDUs may be fragmented, for example due to delay or maximum transmission unit limitations. Fig. 5 shows a group of cells of the same Virtual Path Connection transported over MPLS. In this case, the Virtual Path Identifier (VPI) is the same for all cells, so it can be omitted. The receiving entity deduces the VPI value from the interworking label. If there are several Virtual Channels inside the Virtual Path, cells may have different Virtual Channel Identifier (VCI) values, so the VCI has to be indicated for every cell. If the VCI is omitted for a cell, it is assumed that it has the same VCI as the preceding one. The presence or absence of the VCI is indicated by the VCIP bit (see Fig. 5). In this way, the VCI field (16 bits) has to be included only for the first cell in the group, and for every cell where the VCI changes. If only one Virtual Channel Connection is mapped to a pair of interworking LSPs, then the VPI and VCI are the same for all cells, and both fields can be omitted. In this case the overhead per cell is reduced to 1 octet: the MPLS Interworking Specific Header.

32 bits Transport label (MFA) or PSN Transport Header (PWE3)

Interworking label (MFA) or Reserv. Sequence number Pseudo Wire Header (PWE3)

VCI MPLS Interworking Specific Header (MFA) or 48 octets Control word - ATM Specific octet (PWE3) VCI M (bit 8) : If set to 0, the packet contains an ATM cell. If set to 1, it contains an AAL5 payload VCI 48 octets VCIP (bit 7): Set to 1 when the VCI field is present Reserved (bits 6-5): Set to 0 and ignored upon reception. VCI Payload Type Identifier (bits 4-2): PTI coding of each encapsulated ATM cell. 48 octets Cell Loss Priority (bit 1): CLP value of each encapsulated ATM cell.

. . . . Fig. 5. Transport of cells from an ATM Virtual Path Connection over MPLS

ATM connections are mapped to LSPs (two unidirectional LSPs are required in the case of a bi-directional ATM connection). These interworking LSPs can be grouped in a single transport LSP by using the normal label stacking capability of MPLS. RFC 3496 [18] defines MPLS signaling extensions to establish traffic engineered LSPs that can support the ATM service classes (Constant Bit Rate, Variable Bit Rate, etc.) specified by the ATM Forum. ATM over MPLS is one of the scenarios addressed by the group of Martini drafts published in the IETF Pseudo Wire Emulation Edge to Edge (PWE3) group. [19] defines the transport of ATM over MPLS using encapsulation procedures that are very similar to those defined by the ATM Forum in [16]. Both allow the transport of ATM cells or AAL5 PDUs, fragmented if necessary. However, the scope of the PWE3 architecture [20] is more general than just ATM-MPLS interworking. The drafts of this group use the concept of Pseudo Wires (PWs), which can be implemented with MPLS LSPs or with other types of tunnels, e.g. IP or L2TP (Layer 2 Tunneling Protocol). Different procedures may be used to establish a PW depending on its type. [21] speci- fies how to setup and maintain PWs using the Label Distribution Protocol (LDP) defined in RFC 3036. If MPLS is used, a PW is equivalent to the interworking LSP defined by the ATM Forum, and the Packet Switched Network (PSN) tunnel that contains the PWs is equivalent to the transport LSP defined by the ATM Forum. See Fig. 5. [19] defines an optional “N to 1” mode that maps several ATM VPCs to the same PW. Each cell payload (48 octets) transported in this mode carries 4 octets of overhead (the complete ATM header except for the header error control octet). In [16], each VPC is mapped to a different pair of interworking LSPs, but many interworking LSPs can be multiplexed inside the same transport LSP, so the result is essentially the same. In addition to ATM, a PW can transport other layer 2 protocols, such as Frame Relay and Ethernet. An Ethernet PW emulates a point-to-point Ethernet service over IP or MPLS [22]. See Fig. 6.

PSN (e.g. MPLS) tunnel Pseudo wires Ethernet Ethernet service service

Customer Provider Provider Customer Edge 1 Edge 1 Edge 2 Edge 2

PSN tunnel header Preamble PW header Preamble Start Frame Delim. Control Word (opt.) Start Frame Delim. Frame header Frame header Frame header

Frame data Frame data Frame data

Frame Check Seq. Frame Check Seq.

Fig. 6. Emulated point-to-point Ethernet

MPLS can also be used to provide a more general multipoint Ethernet service over the metropolitan and wide areas, known as Transparent LAN Service or, more re- cently, Virtual Private LAN Service (VPLS) [23]. VPLS is a type of layer 2 VPN service that allows the connection of multiple sites in a single broadcast domain over a provider managed IP or MPLS network. All customer sites in the VPLS appear to be on the same LAN regardless of their location. VPLS can be implemented by estab- lishing a mesh of LSPs among provider edge (PE) routers. The majority of VPLS implementations use the procedures defined in the Lasserre-V. Kompella draft [24], which extends the use of LDP for signaling defined in the Martini draft. This document describes a hierarchical VPLS architecture that adds spoke LSPs between PEs and MTUs (multi-tenant units) or between PEs in different metropolitan areas. See Fig. 7.

IP/MPLS IP/MPLS Metro network Metro network IP/MPLS full mesh spoke Core network full mesh PE PE

PE spoke MTU Fig. 7. Hierarchical VPLS

Other drafts propose to implement VPLS with different procedures. [25] (the K. Kompella draft) uses Multiprotocol BGP for the autodiscovery of VPLS members and for the setup and teardown of the PWs that constitute a given VPLS. [26] uses RADIUS as the PE discovery protocol, and L2TPv3 as the control and data plane protocol. VPLS is one of the three solutions being standardized in the L2VPN working group within IETF for supporting provider-provisioned layer-2 virtual private networks. The other two are Virtual Private Wire Service (VPWS) and IP-Only LAN Service (IPLS) [27,28]. VPWS is a service that provides layer 2 point-to-point con- nectivity (e.g. Frame Relay DLCI, ATM VPI/VCI, point-to-point Ethernet) across an IP/MPLS network. IPLS is a particular type of VPLS that is restricted to IP traffic only [29]. In general VPLS, the interconnected systems may be LAN switches and the PE devices must function as MAC learning bridges. In IPLS, however, the interconnected systems are not LAN switches, but rather are IP hosts or routers, so some simplifications are possible. In IPLS, as in VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their MAC destination addresses, but the maintenance of the MAC forwarding tables is done via signaling, rather than via MAC address learning/aging procedures. Further, IPLS does not require flooding of ARP frames normally, and unknown unicast frames are never flooded as would be the case in VPLS. Also, encapsulation is more efficient in IPLS because the MAC header is stripped while traversing the backbone network. In October 2003, the Metro Ethernet Forum (MEF) published its first phase of Metro Ethernet Services specifications [30]. The MEF has currently defined two Ethernet service types, point to point (E-Line) and multipoint to multipoint (E-LAN), provided over a Metro Ethernet Network (MEN). The user-network interface (UNI) between the customer equipment and the MEN uses standard Ethernet from 10 Mbps to 10 Gbps. Different UNIs are connected by point-to-point or multipoint-to- multipoint Ethernet Virtual Connections (EVCs) that provide unicast, multicast, or broadcast frame delivery. One UNI may support multiple EVCs to other UNIs. The MEF is defining service attributes that may apply to UNIs, to individual EVCs, or to specific classes or service within an EVC, for example: physical interface used, bandwidth profile (Committed Information Rate, Committed Burst Size, ...), and performance parameters (availability, frame delay, jitter, and frame loss). A variety of transport technologies may be used in the MEN. MPLS-based VPLS together with MPLS fast rerouting, which can provide local protection in 50 ms (the standard for SDH/SONET), are well suited to implement reliable metro Ethernet services, and both the Metro Ethernet Forum and the MPLS/FR Alliance are collaborat- ing in this direction. Finally, the solutions for layer 2 transport over MPLS can be used to transport IPv6 packets transparently over an MPLS backbone. Alternatively, IPv6 support can be implemented in PE routers. Once labeled, IPv6 packets are switched in the MPLS network without requiring any change in the core routers [31].

4 Layer 1 Transport over MPLS

The transport of bit streams belonging to either the PDH or the SONET/SDH hierar- chies over MPLS is being studied by both the IETF PWE3 group and the MPLS/FR Alliance. The emulation of TDM circuits with pseudo wires implemented over packet-switched networks raises specific requirements, for example the need to maintain clock jitter and wander within the limits imposed by the appropriate standards in spite of packet delay variations [32]. The draft [33] proposes a method to transport fragments of SONET/SDH channels encapsulated with a Circuit Emulation over Packet (CEP) header, and an optional RTP header, preceded by the MPLS label stack (or alternatively UDP/IP or L2TP headers depending on the type of tunnel used). See Fig. 8a. The CEP header includes a structure pointer, which locates selected octets (J1 or V5) within the SONET/SDH fragments, and a sequence number. The RTP header adds a timestamp used for carrying timing information over the PSN. The transport of PDH (T1, E1, T3, E3) over PW is addressed in [34]. The encapsulation is similar to the one described above. See Fig. 8b. In place of the CEP header, it uses a control word that contains several flags, a length field and a sequence number, following the format defined in [20]. The MPLS/FR Alliance has published an implementation agreement [35] for carri- ers to offer nx64k, T1, E1, T3, and E3 services over MPLS. This IA also uses a control word, called “TDM-MPLS header” in the document. See Fig. 8c. The main dif-

ference is that the TDM bit stream transported after the control word is divided into 48-octet cell payloads formatted with AAL1. The reuse of well-known AAL1 mecha- nisms is expected to facilitate implementations and interworking with circuit emulation based on ATM. The document considers also the compatibility with the ATM pseudo wires defined in [19].

32 bits 32 bits 32 bits

Tunnel label Tunnel label Tunnel label

Pseudo wire label Pseudo wire label Circuit Bundle Identifier label

Flags Structure Ptr Sequence Num 0000 LR R Fr Length Sequence Num 0000 LR Res Length Sequence Num v Extended CEP header AAL1 RTP header (optional) TDM payload (47 octets) RTP header (optional) AAL1

TDM payload TDM payload (47 octets) SONET/SDH fragment . a) SONET/SDH Circuit Emulation b) Structure-Agnostic TDM over c) TDM Transport over MPLS over Packet (draft PWE3) Packet – SAToP (draft PWE3) with AAL1 (MPLS/FR Alliance)

Fig. 8. Proposals for layer 1 transport over MPLS

5 Evolution of MPLS

Although many of the documents cited in this article are still drafts, numerous vendors already implement them in their equipment, and applications such as ATM, FR, and Ethernet over MPLS, BGP/MPLS IP VPNs, VPLS, and Fast Reroute have been demonstrated in multi vendor test scenarios [36]. The work on conformance and interoperability testing, and application deployment continues in several areas, for example multi-class traffic engineering, SLAs for MPLS networks, interconnection between MPLS networks, ATM/FR/Ethernet any- to-any interworking via MPLS, VPLS, and fast restoration. MPLS is also expanding its scope in two directions. Firstly, MPLS was defined within the network: LSPs terminate in network nodes and do not reach the user termi- nals like, for example, ATM virtual connections do. However, in order to offer quality of service guarantees end to end, the access links must be taken into account. The MPLS/FR Alliance is working in this direction, and has already specified an MPLS- based User to Network Interface (UNI) [37]. Secondly, MPLS was defined for packet-switched networks, but it can be applied to circuit-switched networks as well. In addition to using MPLS packet-switched networks for circuit emulation in the user plane, as described in section 4, Generalized MPLS (GMPLS) [38,39] extends the MPLS control plane in order to define control procedures (link management, signaling, and routing) suitable for circuit-switched networks, including SONET/SDH, and the ITU-T Automatically Switched Optical Network (ASON). GMPLS is being defined by the IETF group on Common Control and Measurement Plane (CCAMP). The Optical Internetworking Forum (OIF) has re- used parts of GMPLS in the definition of optical user and network interfaces [40].

References

1. Newman, P., et al: Ipsilon Flow Management Protocol Specification for IPv4. RFC 1953. May 1996. 2. Rekhter, Y., et al: Cisco Systems' Tag Switching Architecture Overview. RFC 2105. Feb. 1997. 3. Rosen, E., et al: Multiprotocol Label Switching Architecture. RFC 3031. Jan. 2001. 4. Rosen, E., Rekhter, Y.: BGP/MPLS VPNs. RFC 2547. March 1999. 5. Awduche, D., et al: Requirements for Traffic Engineering Over MPLS. RFC 2702. Sep. 1999. 6. Le Faucheur, F., et al: MPLS Support of Differentiated Services. RFC 3270. May 2002. 7. Le Faucheur, F., Lai, W.: Requirements for support of Diff-Serv-aware MPLS-TE. RFC 3564. July 2003. 8. Fineberg, V.: QoS Support in MPLS Networks. MPLS/FR Alliance. May 2003. 9. Sharma, V., Hellstrand, F.: Framework for Multi-Protocol Label Switching-based Recovery. RFC 3469. Feb. 2003. 10. Pan, P., et al: Fast Reroute Extensions to RSVP-TE for LSP Tunnels. draft-ietf-mpls-rsvp- lsp-fastreroute-03. July 2003 (work in progress). 11. Wright, D.: Voice over MPLS Compared to Voice over Other Packet Transport Technolo- gies. IEEE Communications Magazine, vol. 40, num. 11, Nov. 2002. 12. MPLS Forum Technical Committee: Voice over MPLS - Bearer Transport Implementation Agreement. MPLSF 1.0. July 2001. 13. UIT-T: Service requirements and architecture for voice services over MPLS. Rec. Y.1261. Dec. 2002. 14. MPLS/Frame Relay Alliance Technical Committee: I.366.2 Voice Trunking Format over MPLS. MPLS/FR 5.0.0. Aug. 2003. 15. Brunnbauer, W., Cichon, G.: AAL2 over IP for radio access networks. IEEE Globecom 2001, San Antonio. Nov. 2001. 16. ATM Forum: ATM-MPLS Network Interworking Version 2.0. Doc. AF-AIC-0178.001. Aug. 2003. 17. ATM Forum: ATM-MPLS Network Interworking Signaling Specification Version 1.0. Doc. AF-CS-0197.000. Aug. 2003. 18. Malis, A.: Protocol Extension for Support of ATM Service Class-aware MPLS Traffic En- gineering. RFC 3496. March 2003. 19. Martini, L.: Encapsulation Methods for Transport of ATM Over IP and MPLS Networks. draft-ietf-pwe3-atm-encap-04. Dec. 2003 (work in progress). 20. Bryant, S., Pate, P.: PWE3 Architecture. draft-ietf-pwe3-arch-06. Oct. 2003 (work in progress). 21. Martini, L.: Pseudowire Setup and Maintenance using LDP. draft-ietf-pwe3-control- protocol-05. Dec. 2003 (work in progress). 22. Martini, L.: Encapsulation Methods for Transport of Ethernet Frames Over IP/MPLS Net- works. draft-ietf-pwe3-ethernet-encap-05. Dec. 2003 (work in progress).

23. Andersson, L.: PPVPN terminology. draft-andersson-ppvpn-terminology-04. Sep. 2003 (work in progress). 24. Lasserre, M., Kompella, V.: Virtual Private LAN Services over MPLS. draft-ietf-l2vpn- vpls-ldp-01. Nov. 2003 (work in progress). 25. Kompella, K., Rekhter, Y.: Virtual Private LAN Service. draft-ietf-l2vpn-vpls-bgp-01. Jan. 2004 (work in progress). 26. Heinanen, J.: Radius/L2TP Based VPLS. draft-ietf-l2vpn-l2tp-radius-vpls-00. Jan. 2004 (work in progress). 27. Andersson, L., Rosen, E.: L2VPN Framework. draft-ietf-l2vpn-l2-framework-03. Oct. 2003 (work in progress). 28. Augustyn, W., Serbest, Y.: Service Requirements for Layer-2 Provider Provisioned Virtual Private Networks. draft-ietf-l2vpn-requirements-01. Feb. 2004 (work in progress). 29. Shah, H.: IP-Only LAN Service (IPLS). draft-ietf-l2vpn-ipls-00. Nov. 2003 (work in progress). 30. Santitoro, R.: Metro Ethernet Services - A Technical Overview. Metro Ethernet Forum, 2003. 31. Tatipamula, M.: IPv6 Integration and Coexistence Strategies for Next-Generation Net- works. IEEE Communications Magazine, vol. 42, num. 1. Jan. 2004. 32. Riegel, M.: Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks. draft-ietf-pwe3-tdm-requirements-04. Jan. 2004 (work in progress). 33. Malis, A.: SONET/SDH Circuit Emulation over Packet (CEP). draft-ietf-pwe3-sonet-03. Oct. 2003 (work in progress). 34. Vainshtein, S., Stein, Y.: Structure-Agnostic TDM over Packet (SAToP). draft-ietf-pwe3- satop-01. Dec. 2003 (work in progress). 35. MPLS/Frame Relay Alliance Technical Committee: TDM Transport over MPLS using AAL1. MPLS/FR 4.0. June 2003. 36. MPLS World Congress 2004 Public Interoperability Event. Test plan and results. Feb. 2004. www.mplsforum.org 37. MPLS/Frame Relay Alliance Technical Committee: MPLS PVC User to Network Interface. MPLS/FR 2.0.1. May 2003. 38. Mannie, E.: Generalized Multi-Protocol Label Switching Architecture. draft-ietf-ccamp- gmpls-architecture-07. May 2003 (work in progress). 39. Berger, L.: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description. RFC 3471. Jan. 2003. 40. Saha, D., Rajagopalan, B., Bernstein, G.: The Optical Network Control Plane: State of Stan- dards and Deployment. IEEE Communications Magazine, vol. 41, num. 8. Aug. 2003.