Internet DRAFT - draft-kamite-l2vpn-vpls-mcast-reqts

draft-kamite-l2vpn-vpls-mcast-reqts






Network Working Group                                          Y. Kamite
Internet-Draft                                                   Y. Wada
Expires: March 19, 2006                               NTT Communications
                                                              Y. Serbest
                                                                     SBC
                                                                T. Morin
                                                          France Telecom
                                                                 L. Fang
                                                                    AT&T
                                                            Sep 15, 2005


   Requirements for Multicast Support in Virtual Private LAN Services
               draft-kamite-l2vpn-vpls-mcast-reqts-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.

   This Internet-Draft will expire on March 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document provides functional requirements for network solutions
   that support multicast in Virtual Private LAN Service (VPLS).  It



Kamite, et al.           Expires March 19, 2006                 [Page 1]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   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 . . . . . . . . . . . . . . . . . . 11
   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) . . . . . . . . . . . . . . . . . 13
     5.4.  SLA Parameters Measurement . . . . . . . . . . . . . . . . 14
     5.5.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
       5.5.1.  Isolation from Unicast . . . . . . . . . . . . . . . . 14
       5.5.2.  Access Control . . . . . . . . . . . . . . . . . . . . 14
       5.5.3.  Policing and Shaping on Multicast  . . . . . . . . . . 14
     5.6.  Access Connectivity  . . . . . . . . . . . . . . . . . . . 15
     5.7.  Protection and Restoration . . . . . . . . . . . . . . . . 15
     5.8.  Minimum MTU  . . . . . . . . . . . . . . . . . . . . . . . 15
   6.  Service Provider Network Requirements  . . . . . . . . . . . . 15
     6.1.  Scalability  . . . . . . . . . . . . . . . . . . . . . . . 15
       6.1.1.  Trade-off of Optimality and State Resource . . . . . . 16
       6.1.2.  Key Metrics for Scalability  . . . . . . . . . . . . . 16
     6.2.  Tunneling Requirements . . . . . . . . . . . . . . . . . . 17
       6.2.1.  Tunneling Technologies . . . . . . . . . . . . . . . . 17
       6.2.2.  MTU of MDTunnel  . . . . . . . . . . . . . . . . . . . 18
     6.3.  Robustness . . . . . . . . . . . . . . . . . . . . . . . . 18
     6.4.  Discovering Related Information  . . . . . . . . . . . . . 18
     6.5.  Operation, Administration and Maintenance  . . . . . . . . 18



Kamite, et al.           Expires March 19, 2006                 [Page 2]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


       6.5.1.  Activation . . . . . . . . . . . . . . . . . . . . . . 18
       6.5.2.  Testing  . . . . . . . . . . . . . . . . . . . . . . . 19
       6.5.3.  Performance Management . . . . . . . . . . . . . . . . 19
       6.5.4.  Fault Management . . . . . . . . . . . . . . . . . . . 20
     6.6.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 20
     6.7.  Hierarchical VPLS support  . . . . . . . . . . . . . . . . 21
     6.8.  L2VPN Wholesale  . . . . . . . . . . . . . . . . . . . . . 21
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26





































Kamite, et al.           Expires March 19, 2006                 [Page 3]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


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 in VPLS.




Kamite, et al.           Expires March 19, 2006                 [Page 4]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


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 March 19, 2006                 [Page 5]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   - 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
      either point-to-point or point-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 March 19, 2006                 [Page 6]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


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.
   In private infrastructures of Layer-2 VPN, particularly in 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 of IP multicast services in 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 March 19, 2006                 [Page 7]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   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 March 19, 2006                 [Page 8]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


      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 IP applications, total amount of
      Ethernet multicast frames will also grow.  In addition,
      considerations of Ethernet layer, such as OAM, are important as
      well.

   - 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.

   [open for discussion]


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

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 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.

      [This part was revised in -01 version]



Kamite, et al.           Expires March 19, 2006                 [Page 9]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


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
   requirement 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 protocol.  For
   example, BPDU (Bridge Protocol Data Unit) for IEEE 802.1D Spanning
   Tree uses multicast MAC address 01-80-C2-00-00-00.  From the
   perspective of IP multicast, however, it is necessary in VPLS to
   flood the BPDU 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
   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 [IGMP/MLD-SNOOP]).  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-



Kamite, et al.           Expires March 19, 2006                [Page 10]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   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 a way to provide the IP multicast of the
      customers with the care of their Layer-3 multicast routing state.
      It MAY consult Layer-3 information to the necessary degree, but
      any information irrelevant to multicast transport SHOULD NOT be
      consulted.

   -  In a solution, Layer-2 control frames SHOULD be flooded by means
      of existing VPLS technique 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.
      [Open for discussion (esp. if the part "by means of existing VPLS
      technique" should be retained, removed, or changed.)]

   -  In a solution, Layer-2 frames that encapsulate Layer-3 multicast
      control packets (e.g.  PIM, IGMP) 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 by means of existing VPLS technique to all PE/
      CEs in a VPLS instance.
      [Open for discussion (esp. if the part "by means of existing VPLS
      technique" should be retained, changed, or removed.)]

4.2.  Static Solutions

   A solution SHOULD allow static configuration by operator's policies,
   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.

   Specifically, it SHOULD allow a case where a common VPLS instance is
   composed of both multicast-VPLS-compliant PEs and non-compliant PEs.
   Since the existing VPLS already has a multicast flooding
   reachability, it is expected that this will enable customers and SPs



Kamite, et al.           Expires March 19, 2006                [Page 11]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   to be getting the benefit of multicast enhancements incrementally.


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.  Note that if VLAN Ids are assigned by the SP, they
   can be altered.

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]
   o  IGMP (v1[RFC1112], v2[RFC2236] and v3[RFC3376])
   o  Multicast Listener Discovery Protocol (MLD) (v1[RFC2710] and
      v2[RFC3810]) (if IPv6 is supported).

   [This part might need more discussion]

   A solution MUST NOT require any special packet processing about
   Layer-3 multicast protocol by the end users.  It MAY require some
   configuration change for minimum necessity 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.





Kamite, et al.           Expires March 19, 2006                [Page 12]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


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, a
   solution MUST support separate multicast domains per VLAN Id.  Note
   that if VLAN Id translation is provided, 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
   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 the 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



Kamite, et al.           Expires March 19, 2006                [Page 13]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   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
   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 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 MIBs).

5.5.  Security

   Solutions MUST provide 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 filtering capabilities inside
   the activated service upon request of each customer (for example,
   MAC/VLAN filtering, IP multicast channels, 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



Kamite, et al.           Expires March 19, 2006                [Page 14]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   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.

5.8.  Minimum MTU

   Multicast applications are often sensitive to packet fragmentation
   and reassembling, so requirement for avoiding fragmentation might be
   stronger than existing VPLS solution.

   A solution SHOULD provide customers with enough committed minimum 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.


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



Kamite, et al.           Expires March 19, 2006                [Page 15]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   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
   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)






Kamite, et al.           Expires March 19, 2006                [Page 16]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   -  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.

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
   (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] [LDP-P2MP] [LDP-MCAST]
   ), etc.

   Note that which variant, point-to-point or point-to-multipoint, is
   used depends largely on the consideration about the trade-off
   mentioned above and the targeted network/application.  Therefore,



Kamite, et al.           Expires March 19, 2006                [Page 17]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   this document does not mandate any specific protocols.

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.

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.

6.5.  Operation, Administration and Maintenance

6.5.1.  Activation

   The activation of multicast enhancement in a solution SHOULD be
   possible:

   o  with a VPLS instance granularity
   o  with a Attachment Circuit granularity (i.e., with a PE-CE Ethernet
      port granularity, or with a VLAN Id granularity when it is a
      service delimiter)
   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:






Kamite, et al.           Expires March 19, 2006                [Page 18]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   o  with a 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 SHOULD provide a mechanism for testing.  Examples specific
   to multicast are:

   -  Checking connectivity per multicast MAC address
   -  Checking 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.  CE-to-CE is considered MAY and PE-to-PE is
   considered SHOULD.

   Also operators will want to make use of a testing mechanism for
   diagnosis and troubleshooting.  In particular, a solution SHOULD be
   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 SHOULD be
   offered to the SP.

      (Note: This part has a number of similar characteristics to
      requirements for Layer 3 Multicast VPN [MVPN-REQ].)

   The provider SHOULD have access to:

   -  Multicast traffic statistics (total traffic conveyed, incoming,
      outgoing, dropped, etc., by period of time)







Kamite, et al.           Expires March 19, 2006                [Page 19]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   -  Information about client multicast resource usage (state and
      throughput)
   -  Performance information relevant to the multicast traffic usage
      (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 distribution tunnels (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 MIBs (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 SHOULD 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.

   o  Fault notification
         Fault notification and trouble tracking mechanisms SHOULD also
         be provided. (e.g.  SNMP-trap and syslog.)

   o  Fault identification and isolation
         A solution SHOULD 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 SHOULD be able to diagnose if an
         entire multicast group is faulty or some specific destinations
         are still alive.

   o  Fault recovery

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



Kamite, et al.           Expires March 19, 2006                [Page 20]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   against unwanted or malicious traffic of them.  This applies to data
   packets.

   Specifically, a multicast VPLS solution SHOULD have measures against:

   -  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



Kamite, et al.           Expires March 19, 2006                [Page 21]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


   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.


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 and
   Vach Kompella 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-04.txt", Feb 2005.

   [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]   IEEE 802.1D-1998, "Information technology -
              Telecommunications and Information exchange between
              systems - Local and metropolitan area networks - Common
              Specifications - Part 3: Media Access Control (MAC)
              Bridges: Revision. This is a revision of ISO/IEC 10038:
              1993, 802.1j-1992 and 802.6k-1992. It incorporates



Kamite, et al.           Expires March 19, 2006                [Page 22]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


              P802.11c, P802.1p and P802.12e.", ISO/IEC 15802-3:, 1998.

   [BIDIR-PIM]
              Handley, M., Kouvelas, I., Speakman, T., and L. Vicisanos,
              "Bi-directional Protocol Independent Multicast (BIDIR-
              PIM), draft-ietf-pim-bidir-07.txt", Sep 2004.

   [CGMP]     Farinacci, D., Tweedly, A., and T. Speakman, "Cisco Group
              Management Protocol (CGMP)",
              ftp://ftpeng.cisco.com/ipmulticast/specs/cgmp.txt , 1996/
              1997.

   [IGMP/MLD-SNOOP]
              Christensen, M., Kimball, K., and F. Solensky,
              "Considerations for IGMP and MLD Snooping Switches,
              draft-ietf-magma-snoop-12.txt", Mar 2005.

   [L2VPN-FR]
              Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual
              Private Networks, draft-ietf-l2vpn-l2-framework-05.txt",
              June 2004.

   [LDP-MCAST]
              Wijnands, I., "Multicast Extensions for LDP,
              draft-wijnands-mpls-ldp-mcast-ext-00.txt", Mar 2005.

   [LDP-P2MP]
              Minei, I., "Label Distribution Protocol Extensions for
              Point-to-Multipoint Label Switched Paths,
              draft-minei-mpls-ldp-p2mp-01.txt", July 2005.

   [MVPN-REQ]
              Morin, T., "Requirements for Multicast in L3 Provider-
              Provisioned VPNs,
              draft-ietf-l3vpn-ppvpn-mcast-reqts-01.txt", July 2005.

   [PIM-SSM]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP, draft-ietf-ssm-arch-06.txt", Sep 2004.

   [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",



Kamite, et al.           Expires March 19, 2006                [Page 23]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


              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.
              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.

   [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-02.txt",
              July 2005.

   [VPLS-BGP]
              Kompella, K. and Y. Rekhter, "Virtual Private LAN Service,
              draft-ietf-l2vpn-vpls-bgp-05.txt", Apr 2005.

   [VPLS-LDP]
              Lasserre, M. and V. Kompella, "Virtual Private LAN
              Services over MPLS, draft-ietf-l2vpn-vpls-ldp-07.txt",
              July 2005.









Kamite, et al.           Expires March 19, 2006                [Page 24]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


Authors' Addresses

   Yuji Kamite
   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
   SBC 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 March 19, 2006                [Page 25]

Internet-Draft         Multicast VPLS Requirements              Sep 2005


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 (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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Kamite, et al.           Expires March 19, 2006                [Page 26]