Network Working Group Y. Kamite, Ed. Internet-Draft Y. Wada Expires: December 28, 2006 NTT Communications Y. Serbest AT&T T. Morin France Telecom L. Fang AT&T Jun 26, 2006 Requirements for Multicast Support in Virtual Private LAN Services draft-ietf-l2vpn-vpls-mcast-reqts-02.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. This Internet-Draft will expire on December 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It Kamite, et al. Expires December 28, 2006 [Page 1] Internet-Draft Multicast VPLS Requirements Jun 2006 specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 3. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Multicast Scalability . . . . . . . . . . . . . . . . . . 7 3.3. Application Considerations . . . . . . . . . . . . . . . . 8 3.3.1. Two Perspectives of the Service . . . . . . . . . . . 8 4. General Requirements . . . . . . . . . . . . . . . . . . . . . 9 4.1. Scope of Transport . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Traffic Types . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Multicast Packet Types . . . . . . . . . . . . . . . . 10 4.2. Static Solutions . . . . . . . . . . . . . . . . . . . . . 11 4.3. Backward Compatibility . . . . . . . . . . . . . . . . . . 12 5. Customer Requirements . . . . . . . . . . . . . . . . . . . . 12 5.1. CE-PE protocol . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. Layer-2 Aspect . . . . . . . . . . . . . . . . . . . . 12 5.1.2. Layer-3 Aspect . . . . . . . . . . . . . . . . . . . . 12 5.2. Multicast Domain . . . . . . . . . . . . . . . . . . . . . 13 5.3. Quality of Service (QoS) . . . . . . . . . . . . . . . . . 14 5.4. SLA Parameters Measurement . . . . . . . . . . . . . . . . 14 5.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.5.1. Isolation from Unicast . . . . . . . . . . . . . . . . 15 5.5.2. Access Control . . . . . . . . . . . . . . . . . . . . 15 5.5.3. Policing and Shaping on Multicast . . . . . . . . . . 15 5.6. Access Connectivity . . . . . . . . . . . . . . . . . . . 15 5.7. Protection and Restoration . . . . . . . . . . . . . . . . 15 5.8. Minimum MTU . . . . . . . . . . . . . . . . . . . . . . . 16 5.9. Frame Reordering Prevention . . . . . . . . . . . . . . . 16 5.10. Fate-Sharing between Unicast and Multicast . . . . . . . . 16 6. Service Provider Network Requirements . . . . . . . . . . . . 17 6.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 17 6.1.1. Trade-off of Optimality and State Resource . . . . . . 17 6.1.2. Key Metrics for Scalability . . . . . . . . . . . . . 18 6.2. Tunneling Requirements . . . . . . . . . . . . . . . . . . 19 6.2.1. Tunneling Technologies . . . . . . . . . . . . . . . . 19 6.2.2. MTU of MDTunnel . . . . . . . . . . . . . . . . . . . 19 6.3. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 19 Kamite, et al. Expires December 28, 2006 [Page 2] Internet-Draft Multicast VPLS Requirements Jun 2006 6.4. Discovering Related Information . . . . . . . . . . . . . 19 6.5. Operation, Administration and Maintenance . . . . . . . . 20 6.5.1. Activation . . . . . . . . . . . . . . . . . . . . . . 20 6.5.2. Testing . . . . . . . . . . . . . . . . . . . . . . . 20 6.5.3. Performance Management . . . . . . . . . . . . . . . . 21 6.5.4. Fault Management . . . . . . . . . . . . . . . . . . . 21 6.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.7. Hierarchical VPLS support . . . . . . . . . . . . . . . . 23 6.8. L2VPN Wholesale . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Kamite, et al. Expires December 28, 2006 [Page 3] Internet-Draft Multicast VPLS Requirements Jun 2006 1. Introduction 1.1. Background VPLS (Virtual Private LAN Service) is a provider service that emulates the full functionality of a traditional Local Area Network (LAN). VPLS interconnects several customer LAN segments over a packet switched network (PSN) backbone, creating a multipoint-to- multipoint Ethernet VPN. For customers, their remote LAN segments behave as one single LAN. In a VPLS, the provider network emulates a learning bridge, and forwarding takes place based on Ethernet MAC learning. Hence, a VPLS requires MAC address learning/aging on a per PW (Pseudo Wire) basis, where forwarding decision treats the PW as a "bridge port". VPLS is a Layer-2 service. However, it provides two applications from the customer's point of view: - LAN Routing application: providing connectivity between customer routers - LAN Switching application: providing connectivity between customer Ethernet switches Thus, in some cases, customers across MAN/WAN have transparent Layer-2 connectivity while their main goal is to run Layer-3 applications within their routing domain. As a result, different requirements arise from their variety of applications. Originally VPLS functionality natively transports broadcast/multicast Ethernet frames. In the current solution, a PE simply replicates all multicast/broadcast frames over all corresponding PWs. Such a technique has the advantage of keeping the P and PE devices completely unaware of IP multicast-specific issues. Obviously, however, it has quite a few scalability drawbacks in terms of bandwidth waste, which will lead to increased cost in large-scale deployment. Meanwhile, there is a growing need for support of multicast-based services such as IP TV. This commercial trend makes it necessary for most VPLS deployment to support multicast more efficiently than before. It is even more true, since customer routers are now likely running IP multicast protocols and those routers and connected switches will be handling huge amount of multicast traffic. Therefore, it is desirable to have more efficient techniques to support IP multicast over VPLS. Kamite, et al. Expires December 28, 2006 [Page 4] Internet-Draft Multicast VPLS Requirements Jun 2006 1.2. Scope of this document This document provides functional requirements for network solutions that support IP multicast in VPLS [VPLS-LDP][VPLS-BGP]. It identifies requirements that MAY apply to the existing base VPLS architecture in order to treat IP multicast. It also complements the generic L2 VPN requirements document [L2VPN-REQ], by specifying additional requirements specific to the deployment of IP multicast in VPLS. The technical specifications are outside the scope of this document. There is no intent to either specify solution-specific details in this document or application-specific requirements. Also, this document does NOT aim at expressing multicast-inferred requirements that are not specific to VPLS. It does NOT aim at expressing any requirements for native Ethernet specifications, either. This document is proposed as a solution guideline and a checklist of requirements for solutions, by which we will evaluate how each solution satisfies the requirements. This document clarifies the needs from both VPN client and provider standpoints and formulates the problems that should be addressed by technical solutions with as a key objective to stay solution agnostic. A technical solution and corresponding service which supports this document's requirements are hereinafter called a "multicast VPLS". 2. Conventions used in this document 2.1. Terminology The reader is assumed to be familiar with the terminology, reference models and taxonomy defined in [L2VPN-FR] and [L2VPN-REQ]. For readability purposes, we repeat some of the terms here. Moreover, we also propose some other terms needed when IP multicast support in VPLS is discussed. - ASM: Any Source Multicast. One of the two multicast service models where each corresponding service can have arbitrarily many senders. Kamite, et al. Expires December 28, 2006 [Page 5] Internet-Draft Multicast VPLS Requirements Jun 2006 - G: denotes a multicast group. - MDTunnel: Multicast Distribution Tunnel, the means by which the customer's multicast traffic will be conveyed across the SP network. This is meant in a generic way: such tunnels can be point-to-point, point-to-multipoint or multipoint-to-multipoint. Although this definition may seem to assume that distribution tunnels are unidirectional, but the wording encompasses bi- directional tunnels as well. - Multicast Channel: (S,G) in the SSM model. - Multicast domain: an area where transmitted multicast data are reachable. In this document, this term has a generic meaning which can refer to Layer-2 and Layer-3. Generally, the Layer-3 multicast domain is determined by Layer-3 multicast protocol for reaching all potential receivers in the corresponding subnet. The Layer-2 multicast domain can be the same as the Layer-2 broadcast domain (i.e., VLAN), but it can be smaller than that with additional control. - PE/CE: Provider/Customer edge Equipment. - S: denotes a multicast source. - SP: Service Provider. - SSM: Source Specific Multicast. One of the two multicast service models where each corresponding service relies upon the use of a single source. - U-PE/N-PE: The device closer to the customer/user is called User facing PE (U-PE) and the device closer to the core network is called Network facing PE (N-PE). - VPLS instance: A service entity manageable in VPLS architecture. All CE devices participating in a single VPLS instance appear to be on the same LAN, composing a VPN across SP network. A VPLS instance corresponds to a group of VSIs that are interconnected using PWs (Pseudo Wires). - VSI: Virtual Switching Instance. VSI is a logical entity in PE that maps multiple ACs (Attachment Circuits) to multiple PWs (Pseudo Wires). The VSI is populated in much the same way as a standard bridge populates its forwarding table. Each PE device may have a multiple VSIs, where each VSI belongs to a different VPLS instance. Kamite, et al. Expires December 28, 2006 [Page 6] Internet-Draft Multicast VPLS Requirements Jun 2006 2.2. Conventions 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 [RFC2119] . 3. Problem Statements 3.1. Motivation Today, many kinds of IP multicast services are becoming available. Over their Layer-2 VPN service, particularly over VPLS, customers would often like to operate their multicast applications across remote sites. Also, multicast service providers using IP-based network are expecting that such Layer-2 network infrastructure will efficiently support them. However, VPLS has a shortcoming in multicast scalability as mentioned below because of its replication mechanisms intrinsic to the original architecture. Accordingly, the primary goal for technical solutions is to solve this issue partially or completely, and provide efficient ways to support IP multicast services over VPLS. 3.2. Multicast Scalability In VPLS, replication occurs at ingress PE when a CE sends (1) Broadcast, (2) Multicast or (3) Unknown destination unicast. There are two well known issues about this: Issue A: Replication to non-member site In case (1) and (3), the upstream PE has to transmit packets to all of the downstream PEs which belong to the common VPLS instance. You cannot decrease the number of members, so this is basically an inevitable situation for most VPLS deployment. In case (2), however, there is an issue that multicast traffic is sent to sites with no members. Usually this is caused when the upstream PE does not maintain downstream membership information. The upstream PE simply floods frames to all downstream PEs, and the downstream PEs forward them to directly connected CEs; however, those CEs might not be the members of any multicast group. From the perspective of customers, they might suffer from pressure on their own resources due to unnecessary traffic. From the perspective of SPs, they would not like wasteful over- provisioning to cover such traffic. Kamite, et al. Expires December 28, 2006 [Page 7] Internet-Draft Multicast VPLS Requirements Jun 2006 Issue B: Replication of PWs on shared physical path In VPLS, a VSI associated with each VPLS instance behaves as a logical emulated bridge which can transport Ethernet across the PSN backbone using PWs. In principle, PWs are designed for unicast traffic. In all cases (1), (2) and (3), Ethernet frames are replicated on one or more PWs that belong to that VSI. This replication is often inefficient in terms of bandwidth usage if those PWs are traversing shared physical links in the backbone. For instance, suppose there are 20 remote PEs belonging to a particular VPLS instance, and all PWs happen to be traversing over the same link from one local PE to its next-hop P. In this case, even if a CE sends 50Mbps to the local PE, the total bandwidth of that link will be wasted up to 1000Mbps. Note that while traditional 802.1D Ethernet switches replicate broadcast/multicast flows once at most per output interface, VPLS often needs to transmit one or more flows duplicated over the same output interface. From the perspective of customers, there is no serious issue because they do not know what happens in the core. However, from the perspective of SPs, unnecessary replication brings the risk of resource exhaustion when the number of PWs increases. In both issue A and B, these undesirable situations will become obvious when the wide-spread use of IP multicast applications by customers results in frequent occurrences of case (2). Naturally the problem will become more serious as the number of sites grows. In other words, we have multicast scalability concerns in VPLS today. 3.3. Application Considerations 3.3.1. Two Perspectives of the Service When it comes to IP multicast over VPLS, there are two different aspects in terms of service provisioning. They are closely related to the functional requirements from two technical standpoints: Layer-2 and Layer-3. - Native Ethernet service aspect This is an aspect mainly from Ethernet network service operators. Their main interest is how to deal with the issue that current existing VPLS cannot always handle multicast/broadcast frames Kamite, et al. Expires December 28, 2006 [Page 8] Internet-Draft Multicast VPLS Requirements Jun 2006 efficiently. Today, wide-area Ethernet services are becoming popular, and VPLS can be utilized to provide wide-area LAN services. As customers come to use various kinds of content distributing applications which use IP multicast (or other protocols which lead to multicast/broadcast in Ethernet layer), the total amount of Ethernet frames will also grow. In addition, considerations of OAM, security and other related points in multicast in view of Layer-2 are important as well. In such circumstances, the native VPLS specipication would not always be satisfactory if multicast traffic is more dominant in total resource utilization than before. The scalability issues mentioned in the previous section are expected to be solved. - IP multicast service aspect This is an aspect mainly from both IP service providers and end users. Their main interest is how to provide IP multicast services transparently but effectively by means of VPLS as a network infrastructure. There are some hopeful applications such as Triple-play (Video, Voice, Data) and Multicast IP-VPN. SPs might expect VPLS as an access/metro network to deliver multicast traffic in an efficient way. Furthermore, in some cases, IP service operators might expect operational simplicity of VPLS. That is, they avoid direct and detailed operation of IP routing. In this case, the multicast delivery mechanism is expected to have not only efficiency but also simplicity. Generally speaking, efficiency and simplicity have trade-off relationship in terms of bandwidth usage and state maintenance, so the best trade-off comes to be highly expected. 4. General Requirements We assume the basic requirements for VPLS written in [L2VPN-REQ] are fulfilled if there is no special reference in this document. 4.1. Scope of Transport 4.1.1. Traffic Types Kamite, et al. Expires December 28, 2006 [Page 9] Internet-Draft Multicast VPLS Requirements Jun 2006 4.1.1.1. Multicast and Broadcast As described before, any solution is expected to have mechanisms for efficient transport of IP multicast. Multicast is related to both issues A and B; however, broadcast is related to issue B only because it does not need membership control. - A multicast VPLS solution SHOULD attempt to solve both issues, if possible. However, since some applications prioritize solving one issue over the other, the solution MUST identify which issue (A or B) it is attempting to solve. The solution SHOULD provide a basis for evaluating how well it solves the issue(s) it is targeting, if it is providing an approximate solution. 4.1.1.2. Unknown Destination Unicast Unknown destination MAC unicast needs flooding, but its characteristic in terms of service aspect is quite different from multicast/broadcast. When the unicast MAC address is learned, the PE changes its forwarding behavior from flooding over all PWs into sending over one PW. Thereby it will require different technical studies from multicast/broadcast, which is out of scope in this document. 4.1.2. Multicast Packet Types Ethernet multicast is used for conveying Layer-3 multicast data. When IP multicast is encapsulated by an Ethernet frame, the IP multicast group address is mapped to the Ethernet destination MAC address (beginning with 01-00-5E in hex). Since the mapping between IPv4 multicast addresses and Ethernet-layer multicast addresses is ambiguous (i.e., multiplicity of 1 Ethernet address to 32 IP addresses), MAC-based multicast forwarding is not totally ideal for IP multicast. Ethernet multicast is also used for a Layer-2 control frames. For example, BPDU (Bridge Protocol Data Unit) for IEEE 802.1D Spanning Tree uses multicast destination MAC address (01-80-C2-00-00-00). Also some of IEEE 802.1ag [802.1ag] Connectivity Fault Management (CFM) messages use a multicast destination MAC address dependent on their message type and application. From the perspective of IP multicast, however, it is necessary in VPLS to flood such control frames to all participating CEs, without requiring any membership controls. As for a multicast VPLS solution, it can only use Ethernet-related information, if you only stand by the strict application of the basic requirement: "a L2VPN service SHOULD be agnostic to customer's Layer Kamite, et al. Expires December 28, 2006 [Page 10] Internet-Draft Multicast VPLS Requirements Jun 2006 3 traffic [L2VPN-REQ]." This means no Layer-3 information should be checked for transport. However, it is obvious this is an impediment to solve Issue A. Consequently, a multicast VPLS can be allowed to make use of some Layer-3-related supplementary information in order to improve transport efficiency. In fact, today's LAN switch implementations often support such approaches to snoop upper layer protocols and examine IP multicast memberships (e.g., PIM snooping and IGMP/MLD snooping [RFC4541]). This will implicitly suggest that VPLS may adopt similar techniques although this document does NOT state Layer-3 snooping is mandatory. If such an approach is taken, careful considerations about Layer-3 state maintenance performance are much needed. In addition, note that snooping approaches sometimes have disadvantages in the system's transparency; that is, one particular protocol's snooping solution might hinder other (especially future) protocol's working (e.g., an IGMPv2-snooping switch vs. a new IGMPv3- snooping one). Also, note that you can take into account other potential alternatives to snooping: - static configuration of multicast Ethernet addresses and ports/ interfaces - multicast control protocol based on Layer-2 technology which signals mappings of multicast addresses to ports/interfaces, such as GARP/GMRP[802.1D], CGMP[CGMP] and RGMP[RFC3488]. On the basis described above, general requirements about packet types are given as follows: - A solution SHOULD support the IP multicast of the customers with the care of their Layer-3 multicast routing state. It MAY consult Layer-3 information to the degree necessary, but any information irrelevant to multicast transport SHOULD NOT be consulted. - In a solution, Layer-2 control frames (e.g., BPDU, 802.1ag CFM) SHOULD be flooded to all PE/CEs in a common VPLS instance. A solution SHOULD NOT change or limit the flooding scope to remote PE/CEs in terms of end-point reachability. - In a solution, Layer-2 frames that encapsulate Layer-3 multicast control packets (e.g., PIM, IGMP(for IPv4), MLD(for IPv6)) MAY be flooded only to relevant members, with control of limiting flooding scope. However, those which encapsulate Layer-3 other control packets (e.g., OSPF, ISIS) SHOULD be flooded to all PE/CEs in a VPLS instance. 4.2. Static Solutions A solution SHOULD allow static configuration by operator's policies, Kamite, et al. Expires December 28, 2006 [Page 11] Internet-Draft Multicast VPLS Requirements Jun 2006 where logical multicast topology does not change dynamically in conjunction with customer's multicast routing. 4.3. Backward Compatibility A solution SHOULD be backward compatible with the existing VPLS solution. It SHOULD allow a case where a common VPLS instance is composed of both PEs supporting the solution and PEs not supporting, and the multicast forwarding enhancement is partially achieved by the compliant PEs. Note again that the existing VPLS solutions already have a simple flooding capability. Thus this backward compatibility will give customers and SPs the improved efficiency of multicast forwarding incrementally as the solution is deployed. 5. Customer Requirements 5.1. CE-PE protocol 5.1.1. Layer-2 Aspect A solution SHOULD allow transparent operation of Ethernet control protocols employed by customers (e.g. Spanning Tree Protocol [802.1D]) and their seamless operation with multicast data transport. Solutions MAY examine Ethernet multicast control frames for the purpose of efficient dynamic transport (e.g. GARP/GMRP [802.1D]). However, solutions MUST NOT assume all CEs are always running such protocols (typically in the case where a CE is a router not aware of Layer-2 details). A whole Layer-2 multicast frame (whether for data or control) SHOULD NOT be altered from a CE to CE(s) EXCEPT for the VLAN Id field, for its transparency. If VLAN Ids are assigned by the SP, they can be altered. Note, however, when VLAN Ids are changed, Layer-2 protocol may be broken in some cases, such as Multiple Spanning Tree [802.1s]. 5.1.2. Layer-3 Aspect Again, a solution MAY examine customer's Layer-3 multicast protocol packets for the purpose of efficient and dynamic transport. If it does, supported protocols SHOULD include: o PIM-SM [RFC2362], PIM-SSM [PIM-SSM], bidirectional PIM [BIDIR-PIM] and PIM-DM [RFC3973] Kamite, et al. Expires December 28, 2006 [Page 12] Internet-Draft Multicast VPLS Requirements Jun 2006 o IGMP (v1[RFC1112], v2[RFC2236] and v3[RFC3376]) (for IPv4 solutions) o Multicast Listener Discovery Protocol (MLD) (v1[RFC2710] and v2[RFC3810]) (for IPv6 solutions). A solution MUST NOT require any special packet processing about Layer-3 multicast protocol by the end users. It MAY require some configuration change as necessary though (e.g., turning explicit tracking on/off in PIM). A whole Layer-3 multicast packet (whether for data or control) which is encapsulated inside Layer-2 frame SHOULD NOT be altered from a CE to CE(s), for its transparency. However, as for Layer-3 multicast control (like PIM Join/Prune/Hello packet), it MAY be altered to the minimum necessary if such partial non-transparency is acceptable from multicast service point of view. 5.2. Multicast Domain As noted in Section 2.1., a term "multicast domain" is used in a generic context for Layer-2 and Layer-3. A solution SHOULD honor customer's multicast domains. It MUST ensure that provided Ethernet multicast domain always encompass customer's corresponding Layer-3 multicast domain. A solution SHOULD optimize those domains' coverage sizes, i.e., ensure that unnecessary traffic is not sent to CEs with no members. Ideally, provided domain size will be close to that of customer's Layer-3 multicast membership distribution; however, it is OPTIONAL to achieve such absolute optimality from the perspective of Layer-3. If a customer uses VLAN and a VLAN Id as a service delimiter (i.e., each VPLS instance is represented by a unique customer VLAN tag carried by a frame through the UNI port), a solution MUST support separate multicast domains per VLAN Id. Note that if VLAN Id translation is provided (i.e., if a customer VLAN at one site is mapped into a different customer VLAN at a different site), multicast domains will be created per set of VLAN Ids which are associated with translation. If a customer uses VLAN but a VLAN Id is not service delimiter (i.e., a VPN is composed in disregard of customer's VLAN Ids), a solution MAY provide separate multicast domains per VLAN Id. A SP does not always have to provide separate domains per VLAN IDs, but it will definitely benefit customer's usage. A solution MAY build multicast domains with the care of Ethernet MAC Kamite, et al. Expires December 28, 2006 [Page 13] Internet-Draft Multicast VPLS Requirements Jun 2006 addresses. It MAY also build with the care of IP addresses inside Ethernet frames. That is, PEs in each VPLS instance might control forwarding behavior and provide different multicast frame reachability depending on each MAC/IP destination address separately. If IP multicast channels are fully considered in a solution, the provided domain size will be closer to actual channel reachability. 5.3. Quality of Service (QoS) Customers require that multicast quality of service MUST be at least on par with what exists for unicast traffic. Moreover, as multicast is often used to deliver high quality services such as TV broadcast, delay/jitter/loss sensitive traffic MUST be supported over multicast VPLS. To accomplish this, the solution MAY have additional features to support high QoS such as bandwidth reservation and flow admission control. Also multicast VPLS deployment SHALL benefit from IEEE 802.1p CoS techniques [802.1D] and DiffServ [RFC2475] mechanisms. Moreover, multicast traffic SHOULD NOT affect the QoS that unicast traffic receives and vice versa. That is, separation of multicast and unicast traffic in terms of QoS is necessary. 5.4. SLA Parameters Measurement Since SLA parameters are part of the service sold to customers, they simply want to verify their application performance by measuring parameters SP(s) provide. Multicast specific characteristics that may be monitored are, for instance, multicast statistics per stream, delay and latency time (time to start receiving a multicast group traffic across the VPN). You can also see about variation in delivery time of a multicast packet to different destination. A solution SHOULD allow providing these parameters with Ethernet multicast level granularity. (For example, multicast MAC address will be one of those entries for classifying flows with statistics, delay and so on.) However, if a solution aims at IP multicast transport efficiency more, it MAY support IP multicast level granularity. (For example, multicast IP address/channel will be entries for latency time.) In order to monitor them, standard interfaces SHOULD also be provided (e.g., standard SNMP MIB Modules). Kamite, et al. Expires December 28, 2006 [Page 14] Internet-Draft Multicast VPLS Requirements Jun 2006 5.5. Security A solution MUST provide customers with architectures that give the same level of security both for unicast and multicast. 5.5.1. Isolation from Unicast Solutions SHOULD NOT affect any forwarding information base, throughput, resiliency of unicast frames; that is, they SHOULD provide isolation from unicast. 5.5.2. Access Control A solution MAY have the mechanisms of multicast filtering capabilities inside the activated service upon the request of each customer (for example, MAC/VLAN filtering, IP multicast channels filtering, and so on) 5.5.3. Policing and Shaping on Multicast A solution SHOULD have the mechanisms of multicast policing and shaping capabilities for a common customer. This is intended to prevent multicast traffic from exhausting resources for unicast inside a common VPN. This might also be beneficial for QoS separation (see section 5.3). 5.6. Access Connectivity First and foremost various physical connectivity types described in [L2VPN-REQ] MUST be supported. For particular reference here, a multicast VPLS MUST allow a situation on which a CE is dual-homed to two different SPs via diverse access networks -- one is supporting multicast VPLS but the other is not supporting (existing VPLS or 802.1Q/QinQ network). 5.7. Protection and Restoration A multicast VPLS infrastructure SHOULD allow redundant paths to assure high availability. Multicast forwarding restoration time MUST NOT be greater than the time of customer's Layer-3 multicast protocols. For example, if a customer uses PIM with default configuration, hello hold timer is 105 seconds, and solutions are required to detect a failure no later than this period. Moreover, if multicast forwarding was not successfully restored Kamite, et al. Expires December 28, 2006 [Page 15] Internet-Draft Multicast VPLS Requirements Jun 2006 (e.g., in case of no redundant paths), a solution MAY have a raising alarm mechanism to notify outage to customers before such hold timer expires. 5.8. Minimum MTU Multicast applications are often sensitive to packet fragmentation and reassembling, so the requirement to avoid fragmentation might be stronger than the existing VPLS solution. A solution SHOULD provide customers with enough committed minimum MTU (i.e., service MTU) for multicast Ethernet frames to ensure that IP fragmentation between customer sites never occurs. It MAY give different MTU sizes to multicast and unicast. 5.9. Frame Reordering Prevention A solution SHOULD prevent frame reordering delivery of customers' multicast traffic. Likewise, for unicast and unknown unicast traffic, it SHOULD NOT increase reordering occurrence in comparison with the existing VPLS. 5.10. Fate-Sharing between Unicast and Multicast In native Ethernet, multicast and unicast connectivity are often managed all together. For instance, 802.1ag CFM Continuity Check message is forwarded by multicast technique as a periodical heartbeat, but it is supposed to check the "whole" traffic continuity regardless of unicast or multicast, at the same time. Hence, the aliveness of unicast and multicast is naturally coupled (i.e., fate- shared) in this customer's environment. However, a multicast VPLS, by nature, is the one which allows to pick up individually customer's multicast and unicast logically in order to solve resource waste issue. Thus this point will bring some customers more or less a new concern that they might have complicated situations in case of failure in either unicast or multicast only. Therefore, there will be an additional requirement for making both connectivity coupled. This means that if either one of them have a failure, the other is also made stopped. If it becomes alive again, the other is also made activated. - It SHOULD be identified if the solution can provide customers with fate-sharing between unicast and multicast connectivity for their LAN switching application. It MAY have a configurable mechanism for SPs to provide that on behalf of customers, e.g., aliveness synchronization, but its use is OPTIONAL. Kamite, et al. Expires December 28, 2006 [Page 16] Internet-Draft Multicast VPLS Requirements Jun 2006 Note that how serious this issue is depends on each customer's stance in Ethernet operation. For example, if all CEs are IP routers i.e., if VPLS is provided for LAN Routing application, such the customer might not need to care about it because both connectivity is assured in IP layer. 6. Service Provider Network Requirements 6.1. Scalability The existing VPLS architecture has major advantages in scalability. For example, P-routers are free from maintaining customers' information owing to PSN tunnel encapsulations. Also a PW's split- horizon technique can prevent loops, making PE routers free from maintaining complicated spanning trees. However, a multicast VPLS needs additional scalability considerations related to its expected enhanced mechanisms. [RFC3809] lists common L2VPN sizing and scalability requirements and metrics, which are applicable in multicast VPLS too. Accordingly, this section deals with specific requirements on the premise of it. 6.1.1. Trade-off of Optimality and State Resource A solution needs to improve the scalability of multicast as is shown in section 3: Issue A: Replication to non-member site Issue B: Replication of PWs on shared physical path For both issues, the optimization of physical resources (i.e. link bandwidth usage and router's duplication performance) will become a major goal. However, there is a trade-off between optimality and usage of state resources. In order to solve Issue A, at least a PE might have to maintain multicast group information of CEs which was not kept in the existing VPLS. This will present us scalability concerns about state resources (memory, CPU, etc.) and their maintenance complexity. In order to solve Issue B, PE and P might have to know some kinds of additional membership information of remote PEs, and possibly additional tree topology information as well, when they are using point-to-multipoint techniques (PIM tree, P2MP-LSP, etc.). Consequently, the scalability evaluation of multicast VPLS solutions needs careful trade-off analysis between bandwidth optimality and Kamite, et al. Expires December 28, 2006 [Page 17] Internet-Draft Multicast VPLS Requirements Jun 2006 state resources. 6.1.2. Key Metrics for Scalability (Note: This part has a number of similar characteristics to requirements for Layer 3 Multicast VPN [MVPN-REQ].) A multicast VPLS solution MUST be designed to scale well with an increase in the number of any of the following metrics: - the number of PEs - the number of VPLS instances (total and per PE) - the number of PEs and sites in any VPLS instance - the number of client VLAN ids - the number of client Layer-2 MAC multicast groups - the number of client Layer-3 multicast channels (groups or source- groups) - the number of PWs and PSN Tunnels (MDTunnels) (total and per PE) Each multicast VPLS solution SHALL document its scalability characteristics in quantitative terms. A solution SHOULD quantify the amount of state that a PE and P device has to support. The characteristics considerations SHOULD include: - the processing resources required by the control plane processing PWs (neighborhood or session maintenance messages, keep-alives, timers, etc.) - the processing resources required by the control plane processing PSN tunnels - the memory resources needed for the control plane - the amount of protocol information transmitted to manage a multicast VPLS (e.g. signaling throughput) - the amount Layer-2/Layer-3 multicast information a P/PE router treats (e.g. traffic rate of join/leave, keep-alives etc.) - the number of multicast IP addresses used (if IP multicast in ASM mode is proposed as a multicast distribution tunnel) - other particular elements inherent to each solution that impacts scalability Another metric for scalability is operational complexity. Operations will naturally become more complicated if the number of managed object (e.g., multicast groups) grows up, or topology changes more frequently. A solution SHOULD note such the factors which lead to operational complexity. Kamite, et al. Expires December 28, 2006 [Page 18] Internet-Draft Multicast VPLS Requirements Jun 2006 6.2. Tunneling Requirements 6.2.1. Tunneling Technologies A MDTunnel denotes a multicast distribution tunnel. This is a generic term of tunneling that carries customer's multicast traffic over the provider's network. In L2VPN service context, it will correspond to a PSN tunnel. A solution SHOULD be able to use a range of tunneling technologies, including point-to-point (unicast oriented) and point-to-multipoint/ multipoint-to-multipoint (multicast oriented). For example, today there are many kinds of protocols for tunneling such as L2TP, IP, (including multicast IP trees), MPLS (including P2MP-LSP [RSVP-P2MP] and P2MP/MP2MP-LSP [LDP-P2MP-MP2MP] ), etc. Note that which variant, point-to-point, point-to-multipoint or multipoint-to-multipoint, is used depends largely on the consideration about the trade-off mentioned above and the targeted network and applications. Therefore, this document does not mandate any specific protocols. A solution, however, SHOULD state reasonable criteria if it adopts a specific kind of tunneling protocol. 6.2.2. MTU of MDTunnel From the view of SP, it is not acceptable to have fragmentation/ assembling so often while packets are traversing MDTunnel. Therefore, a solution SHOULD support a method that provides minimum path MTU of the MDTunnel to accommodate the service MTU. 6.3. Robustness Multicast VPLS solutions SHOULD avoid whatever single points of failures or propose some technical solutions making possible to implement a failover mechanism. 6.4. Discovering Related Information The operation of a multicast VPLS solution SHALL be as light as possible and providing automatic configuration and discovery SHOULD be prioritized. Therefore, in addition to L2VPN discovery requirements shown in [L2VPN-REQ], a multicast VPLS solution SHOULD provide a method that dynamically allows multicast membership information to be discovered by PEs. Such membership information is, for example, a set of multicast addresses. Which kind of information is provided dynamically depends on solutions. Kamite, et al. Expires December 28, 2006 [Page 19] Internet-Draft Multicast VPLS Requirements Jun 2006 6.5. Operation, Administration and Maintenance 6.5.1. Activation The activation of multicast enhancement in a solution MUST be possible: o with a VPLS instance granularity o with an Attachment Circuit granularity (i.e., with a PE-CE Ethernet port granularity, or with a VLAN Id granularity when it is a service delimiter) Also it SHOULD be possible: o with a CE granularity (when multiple CEs of a same VPN are associated with a common VPLS instance) o with a distinction between multicast reception and emission o with a multicast MAC address granularity Also it MAY be possible: o with an IP multicast group and/or channel granularity o with a VLAN Id granularity when it is not a service delimiter 6.5.2. Testing A solution MUST provide a mechanism for testing multicast data connectivity and verify the associated information. Examples that SHOULD be supported which are specific to multicast are: - Testing connectivity per multicast MAC address - Testing connectivity per multicast Layer-3 group/channels - Verifying data plane and control plane integrity (e.g. PW, MDTunnel) - Verifying multicast membership-relevant information (e.g. multicast MAC-addresses/PW-ports associations, Layer-3 group associations) Operators usually want to test if an end-to-end multicast user connectivity is OK before and after activation. Such end-to-end multicast connectivity checking SHOULD enable the end-to-end testing of the data path used by that of customer's data multicast packets. For details, end-to-end checking will have CE-to-CE path test and PE- to-PE path test. A solution MUST support PE-to-PE path test and MAY support CE-to-CE path test. Also operators will want to make use of a testing mechanism for diagnosis and troubleshooting. In particular, a solution SHOULD be Kamite, et al. Expires December 28, 2006 [Page 20] Internet-Draft Multicast VPLS Requirements Jun 2006 enabled to monitor information describing how client multicast traffic is carried over the SP network. Note that if a solution supports frequent dynamic membership changes with optimized transport, the SP's network will tend to incur difficulty in troubleshooting. 6.5.3. Performance Management Monitoring multicast specific parameters and statistics MUST be offered to the SP. (Note: This part has a number of similar characteristics to requirements for Layer 3 Multicast VPN [MVPN-REQ].) A solution MUST provide SPs with access to: - Multicast traffic statistics (total traffic conveyed, incoming, outgoing, dropped, etc., by period of time) A solution SHOULD provide access to: - Information about customer's multicast resource usage (the number of multicast state and throughput) - Performance information relevant to the multicast traffic usage (one-way delay, jitter, loss, delay variations between different destinations etc.) - Alarms when limits are reached on such resources - Statistics on decisions related to how client traffic is carried on MDTunnels (e.g. "traffic switched onto a multicast tree dedicated to such groups or channels") - Statistics on parameters that could help the provider to evaluate its optimality/state trade-off All or part of this information SHOULD be made available through standardized SNMP MIB Modules (Management Information Base). 6.5.4. Fault Management A multicast VPLS solution needs to consider those management steps taken by SPs below: o Fault detection A solution MUST provide tools that detect group membership/ reachability failure and traffic looping for multicast transport. It is naturally anticipated that such tools are well coordinated with testing mechanisms mentioned in 6.5.2. In particular, such mechanisms SHOULD be able to detect Kamite, et al. Expires December 28, 2006 [Page 21] Internet-Draft Multicast VPLS Requirements Jun 2006 multicast failure quickly on par with unicast cases. It needs to obviate the cases where multicast has been in failure for long time while unicast remains alive; such a situation, in many cases, might end up in complicated troubles in customer applications which use a combination of them. However, in multicast, as there are many receivers pertaining to a particular unidirectional traffic, possibly the number of potential detecting points also grows, which will raise scalability concern. Consequently, a fault detection solution SHOULD scale well with consideration of key metrics described in section 6.1.2. o Fault notification A solution MUST also provide fault notification and trouble tracking mechanisms. (e.g. SNMP-trap and syslog.) In case of multicast, one point of failure often affects a number of involved downstream routers/receivers that might be able to raise notification. Hence notification messages MAY be summarized or compressed for operators' easy management. o Fault isolation A solution MUST provide diagnostic/troubleshooting tools for multicast as well. Also it is anticipated that such tools are well coordinated with testing mechanisms mentioned in 6.5.2. In particular, a solution needs to identify correctly the impacted area inside a multicast group by the failure. Then it SHOULD be able to diagnose if an entire multicast group is faulty or some specific destinations are still alive. 6.6. Security A SP network MUST be invulnerable to malformed or maliciously constructed customer traffic. This applies to data packets and control packets both. Moreover, because multicast, broadcast, and unknown-unicast need more resources than unicast, a SP network MUST have high safeguards against unwanted or malicious traffic of them. This applies to data packets. Specifically, a multicast VPLS solution SHOULD have measures against: Kamite, et al. Expires December 28, 2006 [Page 22] Internet-Draft Multicast VPLS Requirements Jun 2006 - invalid multicast MAC addresses (always) - invalid multicast IP addresses (if they are used for forwarding) - malformed Ethernet multicast control protocol (if they are examined) - malformed IP multicast control protocol (if they are examined) - high volume traffic of * valid/invalid customer's control packets * valid/invalid customer's data packets (broadcast/multicast/ unknown-unicast) We show a few additional guidelines below. A solution MAY allow imposing some bounds on the quantity of state used by a VPN. It is intended to prevent out-of-state-resources (i.e., lack of memory, CPU etc.) situations. Also a solutions MAY allow a policing mechanism to limit the unwanted data traffic shown above. In this case, while policing MAY be configurable to the sum of unicast, multicast, broadcast and unknown unicast traffic, it also MAY be configurable to each such type of traffic individually, or to their combination. It is intended to prevent out-of-physical-resources (i.e., lack of bandwidth and forwarding performance) situations. Moreover, mechanisms against customer's frequent changes of group membership MAY be supported. For example, if the core's distribution tunnel is tightly coupled to dynamic changes of customer multicast domain, a kind of dampening function would be possible. 6.7. Hierarchical VPLS support A VPLS multicast solution SHOULD allow a service model by hierarchical VPLS (H-VPLS) [VPLS-LDP]. In other words, a solution is expected to be operable seamlessly with existing hub and spoke PW connectivity. Note that it is also important to take into account the case of redundant spoke connections between U-PEs and N-PEs. 6.8. L2VPN Wholesale A solution MUST allow a situation where one SP is offering L2VPN services to another SP. One example here is a wholesale model that one VPLS interconnects other SPs' VPLS or 802.1D network islands. For customer SP, their multicast transport can obtain enhancement by virtue of multicast VPLS in the wholesaler SP. Kamite, et al. Expires December 28, 2006 [Page 23] Internet-Draft Multicast VPLS Requirements Jun 2006 7. Security Considerations Security concerns and requirements for a base VPLS solution are described in [L2VPN-REQ]. On top of that, we need additional considerations specific to multicast VPLS. Thus a set of security issues have been identified that MUST be addressed when considering the design and deployment of the multicast VPLS. Such issues have been described in Section 5.5 and 6.6. 8. Acknowledgments The authors thank the contributors of [MVPN-REQ] since the structure and content of this document were, for some section, largely inspired from [MVPN-REQ]. The authors also thank Yuichi Ikejiri, Jerry Ash, Bill Fenner, Vach Kompella and Shane Amante for their valuable reviews and feedbacks. 9. References 9.1. Normative References [L2VPN-REQ] Augustyn, W. and Y. Serbest, "Service Requirements for Layer-2 Provider Provisioned Virtual Private Networks, draft-ietf-l2vpn-requirements-06.txt", Jan 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [802.1D] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision and redesignation of ISO/IEC 10038:98), "Part 3: Media Access Control (MAC) Bridges", ISO/IEC 15802-3:, 1998. [802.1ag] IEEE, "Virtual Bridge Local Area Networks: Connectivity Fault Management (Work in Progress)", 2006. [802.1s] IEEE Std 802.1s-2002, "Virtual Bridged Local Area Networks- Amendment 3: Multiple Spanning Trees", 2002. [BIDIR-PIM] Kamite, et al. Expires December 28, 2006 [Page 24] Internet-Draft Multicast VPLS Requirements Jun 2006 Handley, M., Kouvelas, I., Speakman, T., and L. Vicisanos, "Bi-directional Protocol Independent Multicast (BIDIR- PIM), draft-ietf-pim-bidir-08.txt", Oct 2005. [CGMP] Farinacci, D., Tweedly, A., and T. Speakman, "Cisco Group Management Protocol (CGMP)", ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt , 1996/ 1997. [L2VPN-FR] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks, draft-ietf-l2vpn-l2-framework-05.txt", June 2004. [LDP-P2MP-MP2MP] Minei, I. and I. Wijnands, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to- Multipoint Label Switched Paths, draft-ietf-mpls-ldp-p2mp-00.txt", Feb 2006. [MVPN-REQ] Morin, T., "Requirements for Multicast in L3 Provider- Provisioned VPNs, draft-ietf-l3vpn-ppvpn-mcast-reqts-08.txt", May 2006. [PIM-SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP, draft-ietf-ssm-arch-07.txt", Oct 2005. [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., and V. Jacobson, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Kamite, et al. Expires December 28, 2006 [Page 25] Internet-Draft Multicast VPLS Requirements Jun 2006 Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group Management Protocol (RGMP)", RFC 3488, February 2003. [RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. [RSVP-P2MP] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to RSVP-TE for Point to Multipoint TE LSPs, draft-ietf-mpls-rsvp-te-p2mp-05.txt", May 2006. [VPLS-BGP] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling, draft-ietf-l2vpn-vpls-bgp-08.txt", Jun 2006. [VPLS-LDP] Lasserre, M. and V. Kompella, "Virtual Private LAN Services Using LDP, draft-ietf-l2vpn-vpls-ldp-09.txt", June 2006. Kamite, et al. Expires December 28, 2006 [Page 26] Internet-Draft Multicast VPLS Requirements Jun 2006 Authors' Addresses Yuji Kamite (editor) NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421 Japan Email: y.kamite@ntt.com Yuichiro Wada NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Japan Email: yuichiro.wada@ntt.com Yetik Serbest AT&T Labs 9505 Arboretum Blvd. Austin, TX 78759 USA Email: Yetik_serbest@labs.sbc.com Thomas Morin France Telecom R&D 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: thomas.morin@francetelecom.com Luyuan Fang AT&T Labs 200 Laurel Avenue Middletown, NJ 07748 USA Email: luyuanfang@att.com Kamite, et al. Expires December 28, 2006 [Page 27] Internet-Draft Multicast VPLS Requirements Jun 2006 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 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kamite, et al. Expires December 28, 2006 [Page 28]