Network Working Group Ping Pan Internet Draft (Hammerhead Systems) Expiration Date: December 2005 July 2005 Dry-Martini: Supporting Pseudo-wires in Sub-IP Access Networks draft-pan-pwe3-over-sub-ip-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Abstract Several recent developments have significantly affected the carrier access networks. First, all large carrier backbones have migrated to MPLS. Second, carriers are upgrading access circuits with less expensive and high-speed Ethernet. Finally, the carriers will be offering advanced data services over the access network infrastructure. Subsequently, the Pan [Page 1] Internet Draft Dry-Martini July 2005 carriers have to face challenges in migration cost, data transport efficiency and edge-to-edge user traffic management. The Dry-Martini architecture is designed to help the carriers to alleviate these challenges. It provides an approach to establish and maintain pseudo-wires over any access network infrastructure, while stripping off much of the IP/MPLS routing and signaling features that are irrelevant in access network. As a result, all the existing transport equipment, such as SONET/SDH MSPP, can provide MPLS pseudo- wire functionality without much change to the existing platform. Further, due its simplicity, this approach allows the new access devices, such as PONĖs and Ethernet CPEĖs, to maintain low cost, while being able to interface with MPLS networks. This document assumes that the reader has at least some familiarity with MPLS and pseudo-wire technologies. 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Introduction The challenges in expanding carrier networks are mainly taking place at access. The driver behind the access network expansion is to bring high-speed links toward the end users so that the carriers can offer extensive data services. Subsequently, the carriers have to face a number of issues: First of all, how to deal with the existing installation? Traditionally, carrier access networks consist of DS1/3 and OC3/12 circuits supporting services such as Frame Relay and ATM. The networks are constructed with either SONET/SDH rings, and/or leased lines. Most of the customer traffic is carried over circuit interfaces, despite the fact that IP data is becoming the predominating traffic type. Carrying packets over circuit networks cannot take the advantage of statistical multiplexing gains that has made packet networks very efficient. According to a recent report from AT&T [ATT], the multiplexing gain in data-aware access/metro networks is in the range Pan [Page 2] Internet Draft Dry-Martini July 2005 of 3-4. Second, how to manage and control the access networks? Most likely, the carriers would like to adapt a single, coordinated architecture in access, metro and backbone networks. ItĖs noteworthy that such architecture does not necessarily imply that all traffic flows will be packetized and individually routed as IP packets. It simply means that it is preferable to have a somewhat consistent control-plane throughout the network. Given the backbone has already migrated to IP/MPLS, naturally, the rest of the network should try to adapt to something similar. Finally, how to deal with the emerging Metro Ethernet? Access technology normally changes very 8-10 years. Most recently the carrier transport Ethernet technology has become the choice of access in metro network. When examining the previous network access technologies, we will notice that X.86, Frame Relay, ATM and Ethernet all share the same set of properties at time when they were deployed: (a) More bandwidth: this helps data statistical multiplexing (b) Robustness: failure detection and recovery are critical (c) Traffic assurance: user flows need to be shaped and policed (d) Cheap: this is the essential element for wide deployment Hence, this poses the question: is it possible to engineer the access network in such as a way that they donĖt have to be re-engineered very so often? One way to solve all the above issues is to replace the entire network equipment (including those in access and metro area) with MPLS routers, and interconnect them with big Ethernet pipes. The problem with this approach is in its willful ignorance of carrier economics. Unless it is green-field deployment, we believe that all carriers will have to focus on migration and operation cost as they expand data-friendly access network, and leverage the existing access infrastructure as much as possible. In this document, we will present the Dry-Martini architecture that provides a solution that is transparent to Layer-2 access technologies and can aggregate any type of data traffic from access into metro core. Before the description of the architecture, we first evaluate some of the important components, and gain a better understanding on what is and is not important in this area of the network. Pan [Page 3] Internet Draft Dry-Martini July 2005 3. Components of the Architecture The figure below illustrates various relevant components in the architecture. | | |<-- label negotiation -->| +--------+ +----------+ +----------+ User-1 -----| Access | | Metro | | MPLS | | Device |-------------|Aggregator|----| Backbone |-... User-2 -----| | sub-IP | | | Router | +--------+ data trunks +----------+ +----------+ | | |<----- Pseudo-wires ---->| Figure-1: A simplistic view of the carrier network 3.1. Access Devices and Data Trunks Traditionally, a typical Access Device can be a circuit aggregation switch (e.g. CPE), or a SONET/SDH switch (e.g. MSPP and ADM). The data trunks are normally DS1/DS3 circuits running Frame Relay and ATM, or OC-3/OC-12 circuits running ATM. At Access Device, each user flow is mapped to one of the circuits. In recent years, the carriers have begun to deploy high-speed Ethernet circuits and lambda (photonic) as data trunks to the customers. Access Devices have evolved as well. The PONs (Passive Optical Networks) in various flavor have been evaluated and deployed for high-speed network access. The links that interconnect the access devices and aggregators can be (and not limited to) lambda (photonic), SONET/SDH cross-connects, ATM/Frame Relay circuits, or Ethernet VLAN connections. For clarity, we denote these links as sub-IP data trunks, the networks that setup and maintain sub-IP data trunks, as sub-IP networks. It is important to realize that, it is carrierĖs interest to aggregate as many user flows into a sub-IP data trunk as the SLA would allow, in taking the advantage of statistical multiplexing gains. Pan [Page 4] Internet Draft Dry-Martini July 2005 To support wide deployment, the Access Device must be reliable, simple-to-manage and cheap. Normally, each access device connects to the metro backbone through two links for protection purpose. Extensive IP routing functionality at access devices is not always necessary. 3.2. Metro Aggregators Depending on metro network topology, each aggregator may process traffic from dozens to hundreds of access devices. Upon grooming user traffic together, the aggregators feed the traffic toward the MPLS core. Typically, each aggregator can be a combination of multiple systems. They are responsible for multiplexing and de-multiplexing DS3/1/0 or OC-n circuits, and switching data packets. As the metro network becomes more data-centric, the aggregators are expected to be more data friendly. Some of the key requirements in supporting data traffic on aggregators are per-user-flow QoS, data trunk OAM, and protection and recovery in event of both equipment and facility failures. 3.3. Packet Flow ID Each user flow can be uniquely identified with a packet flow ID. Depending on the transport technology, the flow ID can be (and not limited to) Frame Relay DLCI, ATM VPI/VCI, Ethernet VLAN (including VLAN tag via Q-in-Q), and MPLS Label. Using packet flow IDs enables the carriers to offer logical circuits to the customers, and, thereby, manage and control user traffic at per-flow granularity. 3.4. Pseudo-wire Encapsulation Aggregating multiple flows into a shared data trunk requires packet flow ID encapsulation. There have been a number of encapsulation methods for various technologies, such as Q-in-Q for Ethernet. Draft-martini, known for its original designer Luca Martini, has presented an encapsulation method that enables the aggregation of Pan [Page 5] Internet Draft Dry-Martini July 2005 different types of Layer-2 flows into a single trunk, while retain some of the important service-specific characteristics ([PWE3-ETHER], [MARTINI-ATM], [MARTINI-FR]). Essentially it is to encapsulate the packets belong to a user flow with a MPLS header and a Layer-2 specific control word. The MPLS label [RFC3032] in the header makes the flow unique throughout the network. Upon entering the network, each encapsulated flow is referred as a ŸPseudo-wire÷. Originally, draft-martini was designed to help the carriers to aggregate Layer-2 traffic over a common MPLS/IP backbone via MPLS Label Edge Routers (LERĖs). Each Layer-2 flow is mapped to a Pseudo- wire. The setup and maintenance of each Pseudo-wire involve two provider edge nodes (PEĖs), which exchange connection and encapsulation label information through targeted LDP [PWE3-CTRL]. Upon closer evaluation, we note the following: one of the most important benefits in Pseudo-wire is that the carrier can handle and process user traffic at per-flow granularity independent of the underlying networking technology. On the contrary, encapsulation mechanisms, such as Ethernet Q-in-Q, will only operate in a specific Layer-2 environment. We will elaborate this point later on. 3.5. Label Negotiation Pseudo-wires operate between two network nodes. Each Pseudo-wire consists of two unidirectional paths, one in each direction. Each path can be uniquely identified by the triple . Prior to data transmission, two nodes need to know the value of the encapsulation-label for each user flow. As mentioned above, the most common label negotiation mechanism is target LDP [LDP, PWE3-CTRL], where two edge nodes can initiate a LDP session and exchange label binding information to setup the Pseudo- wires. The actual Pseudo-wire setup sequence is very simple. However, the overhead in processing LDP protocol itself, such as LDP session and adjacencies management and peer discovery can be quite elaborate. This is because the original LDP specification was designed to establish MPLS LSPĖs among routers in the backbone environment. Hence, applying the same label negotiation mechanism in access network may be an over-kill. We will discuss this issue later on. Pan [Page 6] Internet Draft Dry-Martini July 2005 3.6. Traffic Policing and Assurance Most of the data applications do not require stringent QoS. In todayĖs backbone networks, the carriers over-provision the network links, and rely on DiffServ to overcome temporary traffic congestion. Thus, per-flow shaping and rate limiting does not apply in enterprise and backbone networks. However, we should not ignore QoS guarantees (or SLA) as an essential part of carrier service offering. As the access network begins to expand, the mixture of existing low- speed circuit infrastructure and high-speed Ethernet links will cause network resource heterogeneously distributed. As carriers continue to lease service lines to enterprise customers, and offer QoS-sensitive data applications (e.g. voice) to consumer users, supporting per- user-flow QoS becomes increasingly important. 3.7. Demarcation Points and Pseudo-wire Switching The concept of UNI (User-Network Interface) has been foreign to the Internet, where the entire network supposes to be distributed and open. From user application perspective, this is true: the end-users should never observe the existence of any UNI interface, as elaborately defined in ATM. Nevertheless, in access/metro area, there remain demarcation points where traffic from one segment of the network is transferred to another accordingly to a set of rules between carriers. For instance, there likely exists a demarcation point between metro network (aggregators) and the backbone (MPLS/IP routers). As such, depending on carrierĖs deployment scenario, the Pseudo-wires coming from access networks need to be policed before switching toward the backbone. Another demarcation point where subsequent Pseudo-wire switching is useful is between two metro networks. Depending on the bilateral (and multilateral) agreement, user flows in the form of Pseudo-wires will be handed off (or switched, stitched) from one network to another. Pan [Page 7] Internet Draft Dry-Martini July 2005 4. Dry-Martini Architecture The Dry-Martini Architecture is based on draft-martini as the encapsulation method for aggregating user flows into carrier networks, and strip off much of the IP/MPLS routing and signaling features that are irrelevant in access networks. Because we have relaxed and simplified much of the constraints in the original design, we refer this architecture as Ÿdry-martini÷. Our rational is as follows: the operation of Pseudo-wires involves two endpoints of the connection, and is almost independent from the operation taking place within the underlying network. Hence, we argue that the pseudo-wire concept is applicable in all networks. (Note that much of the concept of supporting Pseudo-wires over any packet networks (PSN) has been assumed in the IETF PWE3 architecture [PWE3- ARCH].) Further, pseudo-wire encapsulation is transparent to all the existing Layer-2 technologies, and, perhaps, to the access technologies that will get deployed in the future (such as WiMax). Therefore, if we always handle user flows at Pseudo-wire layer, it will provide carriers with a uniformed and consistent method to aggregate, police and manage all types of data flows. This will subsequently simplify carrier service migration and integration. Another advantage in Pseudo-wires is in its flexibility to map user applications into flows. For example, today, the carriers can packetize voice streams into Pseudo-wires [SATOP, CESoPSN] and transport them over the backbone. Voice service requirements can be retained with some basic QoS treatment (such as clocking recovery). This implies that, if the carriers can manage data flows as Pseudo-wires with QoS, redundancy and OAM features, then any stream traffic (such as video and voice) sent over Pseudo-wires will always get appropriate edge-to-edge SLA guarantees. In essence, Pseudo-wire can be the convergence layer for transporting data flows over any network. Figure 2 shows the Pseudo-wire in relation to user applications and underlying transport network. Pan [Page 8] Internet Draft Dry-Martini July 2005 +-------------------+ user +-------------------+ | Payload | applications | Payload | | (IP, L2 data, ... |<==================>| (IP, L2 data, ... | | packetized voice) | | packetized voice) | +-------------------+ +-------------------+ | | convergence | | | | layer | | | Pseudo-wires |<==================>| Pseudo Wires | | | | | +-------------------+ +-------------------+ | Layer 2 | data service | Layer 2 | |(Ethernet, ATM...) |<==================>|(Ethernet, ATM...) | | | | | +-------------------+ +-------------------+ | Layer 1 | physical transport | Layer 1 | | (optical, TDM...) |<==================>| (optical, TDM...) | | | | | +-------------------+ +-------------------+ Figure 2: The logical layering model applied in Dry Martini architecture Within the Dry-Martini architecture, the carriers can operate Pseudo-wires over any sub-IP networks: Application 1: The carriers may create Pseudo-wires from SONET/SDH access devices (such as MSPPĖs) directly, and aggregate user Ethernet traffic over the existing metro infrastructure. TodayĖs typical EoS (Ethernet-over-SONET) solution is to use VCAT and GFP, and map Ethernet physical port to a Virtual Concatenation Group (VCG). With the Dry-Martini architecture, the carriers can map multiple Ethernet flows into a single VCG. This can improve access bandwidth utilization significantly. Application 2: The carriers may choose to create Pseudo-wires and aggregate data packets over the existing leased ATM or Frame Relay circuits. Once again, improving link utilization (a.k.a. statistical multiplexing gains) may be an important economical factor here. Application 3: The carriers can always aggregate multiple user flows into a single wavelength off the PONĖs, and process the flows at aggregators. In all the applications, carriers use the method of their choice to Pan [Page 9] Internet Draft Dry-Martini July 2005 manage the sub-IP data trunks: GMPLS for optical networks, PNNI/SPVC for ATM infrastructure, Ethernet signaling for metro Ethernet, or, simply, static configuration for SONET/SDH connection provisioning. The key is that, as long as there is an operational sub-IP data trunk between two network nodes, the carrier may establish Pseudo-wires to aggregate data flows over it. In the architecture, the access devices do not need to support much of the IP functionality, such as per-packet IP routing, and routing protocols. All data flows are handled as circuit-like Pseudo-wires. Given the access devices have only a couple of connections to the metro backbone, the use of IP routing would be very limited. It is the aggregators that need to be able to interface with both access networks and the MPLS/IP network, and aggregate and switch user traffic in between. In the remaining of the document, we will outline the data-plane and control-plane issues in supporting the Dry-Martini architecture, and articulate some of the important features that are actually needed in this area of the network. 5. Data-Plane Operation in the Dry-Martini architecture As an example of the operation, we consider the network setup shown in Figure-1. Suppose that there are N user flows arriving at the Access Device. The user flows are provisioned prior to the actual data transmission. A typical user flow may be a privately leased line for an enterprise customer, or a high-speed Ethernet connection to a residential location. Thus, we assume that all the user flows have a relatively long duration, and each flow may have some QoS parameters (such as average rate) associate with it. Upon the reception of a packet from a user, the access device will first search for the corresponding flow information (such as the VLAN tag) from its local cached database. If a match is found, it will run a simple CAC (Call Admission Control) algorithm to ensure QoS compliance and encapsulate the packet with a new packet flow ID, and then transmit the packet toward the aggregator. The packet flow ID is negotiated with the aggregator ahead of time. Multiple user flows can share a common data trunk with different flow IDĖs. At the aggregator, the packet flow ID will be examined and stripped off. The packets will then be forwarded toward the core. Pan [Page 10] Internet Draft Dry-Martini July 2005 The packet forwarding sequence from the aggregator to the access device would be same. All packet encapsulation should be the same as the ones defined in draft-martini. However, we do not mandate the MPLS label as the only packet flow ID. Depending on the flexibility of the access device itself, the packet flow ID can be something different, for instance, Ethernet VLAN tag. Ethernet VLAN can be used as the Pseudo-wire flow ID between access devices and aggregators. This is reasonable for the following reasons: first, given the network size between access devices and aggregators, VLAN scaling (that is, 4000 VALN tags per interface) should not a real problem. Second, some of the access devices may not have the ability to support various MPLS label manipulation (push, pop and stack) operations. In summary, the data-plane requirement on ant access device is very trivial. No per-packet routing lookup is required. However, the access device needs to be able to police user traffic on per-flow basis. The procedure on the aggregator is similar, expect that the aggregators interface with the core, and may need to exercise more extensive packet processing functions with the core routers. 6. Control-Plane in the Dry-Martini architecture As mentioned before, label negotiation takes place between the access devices and the aggregators. In practice, there are two general approaches in setting up Pseudo- wire labels: in-band and out-band. The in-band approach is to exchange control messages over the sub-IP data trunks. The out-band approach is to setup labels through an external management system. There are a number of ways to exchange IP control messages (e.g., LDP messages) between the edge nodes. One approach is to route the messages through the underlying sub-IP network. For example, in SONET/SDH networks, the control messages may utilize DCC channels to communication with each other. However, this would require every node in the sub-IP network to be IP-capable, which may be not practical in many of the operational networks. We propose to "tunnel" all control packets through the sub-IP data trunks as regular data payload from the edge. The advantage here is Pan [Page 11] Internet Draft Dry-Martini July 2005 that the exchange of control messages will not disturb the operation in the underlying sub-IP network. For the user packets to be encapsulated with a MPLS header, we require control packets to be encapsulated with "IP4 Explicit NULL Label" [RFC2032]. At the destination, the label is popped, and the control packets are delivered to the control plane for further processing. For the user packets to be encapsulated with a VLAN tag, we propose to use a special VLAN value for control message delivery. Once again, at the destination, the messages are picked up for further examination. 6.1. Option 1: Target LDP The conventional method is to run target LDP in-band between access device and aggregator. For clarity, we repeat the procedure described in [PWE3-CTRL] in the context of setting up Pseudo-wires in sub-IP networks. Each Pseudo-wire consists of two unidirectional paths, one in each direction. The access device and the aggregator are the two edge nodes. Each edge initiates the setup of the path on behalf of ingress Layer-2 traffic. Each path is uniquely identified by the triple , where the VCID is a 32-bit quantity that must be unique in the context of a single LDP session between two edges. For a given Pseudo-wire, the same VCID must be used when setting up both paths. In this case, the access device needs to implement target LDP to communicate with the aggregator. 6.2. Option 2: Lightweight Signaling In certain scenarios, using target LDP for Pseudo-wire label negotiation is questionable. LetĖs first evaluate the tradeoffs in supporting target LDP in this part of the network. As mentioned before, much of the LDP functionality is irrelevant in setting up Pseudo-wires. Its built-in discovery and session and adjacencies management algorithms are originally designed to operate in a distributed networking environment and interface among routers. Pan [Page 12] Internet Draft Dry-Martini July 2005 However, in access networking environment, the network configuration is most likely a simple spoke topology. In most cases, the access devices and the aggregators are one-hop away. From the operation point of view, the carriers would like to control the label allocation and distribution at the aggregators, rather than from some customer-location access devices. The actual Pseudo-wire negotiation signaling should be more client-server style, instead of peer-to-peer as in LDP. Further, letĖs examine the development and performance cost. One of the primary requirements in this part of the network is low-cost. Supporting MPLS signaling and IP routing protocols will no doubt require more expensive components in developing the access devices. Typically, each metro aggregator may interface with hundreds of access devices. Supporting target LDP implies that each aggregator may need to maintain hundreds of TCP and LDP sessions at control- plane. This adds unnecessary performance overhead to the aggregators. We believe that there is a need for developing a light-weight Pseudo-wire negotiation signaling protocol for access networks. Some of the key elements of the protocols are: (a) Client-server signaling: If we look at the operation of Frame Relay LMI, in practice, the DTE-DCE relationship is nearly identical to that of access devices and metro aggregators. (b) Light-weight: The complexity of the protocol should be similar to that of ICMP. In other words, every access device should be able to support it without much cost associated with it. (c) In-band: This will increase the automation capability during Pseudo-wire setup. Further, in-band protocols can always help the network nodes in failure detection. The detail design of the lightweight protocol is beyond the scope of this architecture document. We will provide its design elsewhere. In summary, using a lightweight protocol would enable the access devices to setup pseudo-wires without dealing with IP routing and full-stack MPLS signaling. When designed correctly, the aggregators would have an efficient control-plane interface with the access devices. Pan [Page 13] Internet Draft Dry-Martini July 2005 6.3. Option 3: Pseudo-wire Proxy This method is to deploy Ÿproxies÷ to manage Pseudo-wire allocation and distribution. Figure 3 shows its configuration. The Pseudo-wire proxy is a logical entity that can operate in carrierĖs NOC, or on metro aggregators. +-----------------+ +---|Pseudo-wire Proxy|---+ | +-----------------+ | | | +--------+ +----------+ +----------+ User-1 -----| Access | | Metro | | MPLS | | Device |-------------|Aggregator|------| Backbone | User-2 -----| | sub-IP | | | Router | +--------+ data trunks +----------+ +----------+ | | |<--------- OAM --------->| Figure-3: Pseudo-wire management with a Pseudo-Wire Proxy The operation sequence can be as follows: a customer negotiates with the carrier on his network access service, which may include an extensive set of business and technical conditions. During the negotiation, the carrier knows where the customerĖs traffic will enter the network, and the access devices, the aggregators and the data trunks to be used. From the proxy, the carrier assigns the Pseudo-wire labels to both the access device and the aggregator through the management interface (e.g. SNMP). This type of out-band, static Pseudo-wire configuration is simple to implement. However, without some type of direct communication between the access devices and the aggregators, any failure in the data trunk will not be detected, or too late to be notified. Hence, we recommend enabling the Pseudo-wire OAM functionality when operate in this mode. Pan [Page 14] Internet Draft Dry-Martini July 2005 7. Carrier Deployment Considerations 7.1. Pseudo-wire Switching As shown in Figure 1, the aggregators interface with the access devices via pseudo-wires, and can interface with the core routers with MPLS or Pseudo-wires. By switching pseudo-wires between the access networks and the metro core, the carriers would have the ability to control the user flows edge-to-edge. Much of the work in Pseudo-wire switching is taking place in IETF at the moment. We will not expand the description any further at this point. 8. Security Considerations This document extends the use of PWE3 to sub-IP networks. It has the same security requirements as in PWE3. 9. Contributors Tad Hofmeister, Tedi Tedijianto and Calcin Leung have contributed to the original dry-martini ideas back in the fall of 2002. Much of the ideas and concepts have been thoroughly discussed and validated with a number of my colleagues in Hammerhead Systems and operation and architecture folks in various carriers. 10. Normative Reference [ATT] T. Afferton, et al, "Packet Aware Transport for Metro Networks", IEEE Network Magazine, April 2004. [RFC3032] E. Rosen, et al, "MPLS Label Stack Encoding". [PW-CTRL] L. Martini, et al, "Pseudo-wire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-14.txt [LDP] L. Andersson, et al, "LDP Specification", draft-ietf-mpls- rfc3036bis-00.txt [PWE3-ARCH] S. Bryant, P. Pate, "PWE3 Architecture", draft-ietf- Pan [Page 15] Internet Draft Dry-Martini July 2005 pwe3-arch [PWE3-ETHER] L. Martini, et al, "Encapsulation Methods for Transport of Ethernet Frames over IP/MPLS Networks", draft-ietf-pwe3-ethernet- encap [MARTINI-ATM] L. Martini, et al, "Encapsulation Methods for Transport of ATM Cells/Frame over IP and MPLS Networks", draft-martini-atm- encap-mpls [MARTINI-FR] C. Kawa, et al, "Frame Relay Encapsulation over Pseudo- wires", draft-martini-frame-encap-mpls [CESoPSN] A. Vainshtein, et al, ?Structure-aware TDM Circuit Emulation Service over Packet Switched Network?, IETF Draft 11. Informative References [PWE3-TRANSPORT] L. Martini, et al, "Transport of Layer 2 Frames over MPLS", draft-martini-l2circuit-trans-mpls [SAToP] A. Vainshtein, Y. Stein, ?Structure-Agnostic TDM over Packet?, IETF Draft [TDMoIP] Y. Stein, et al, ?TDM over IP?, IETF Draft [CEP] A. Malis, ?SONET/SDH Circuit Emulation over Packet?, IETF Draft 12. Author Information Ping Pan Hammerhead Systems 640 Clyde Court Mountain View, CA 94043 e-mail: ppan@hammerheadsystems.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights Pan [Page 16] Internet Draft Dry-Martini July 2005 might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Pan [Page 17]