Internet DRAFT - draft-watkinson-l2vpn-pnni-psn-framework

draft-watkinson-l2vpn-pnni-psn-framework



   Internet Draft                                             D. Watkinson
   Document: draft-watkinson-l2vpn-pnni-psn-framework-01       M. Aissaoui
   Expires: January 2005                                          M. Bocci
                                                                   Alcatel
                                                                 July 2004



                  Framework for PNNI to PSN Interworking



Status of this Memo


   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.
   
   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.
   
   
Abstract
   
   This document defines the framework for interworking mechanisms
   between PNNI signaled ATM networks and the set of Public Switched
   Networks (PSN) supported by this working group.



Table of Contents
   
   Status of this Memo................................................1
   Abstract...........................................................1 
   Table of Contents..................................................1 
   1. Introduction....................................................2 
   1.1. Conventions used in this document.............................2 
   1.2. Objectives and Scope of the Document..........................2 
   2. ATM Signaled to PSN to ATM Signaled Networks....................3 
   3. ATM Signaled to PSN Networks....................................5 
   3.1. Signaling and Routing.........................................5 
   3.2. Data Format...................................................6 
   3.3. QoS...........................................................7 
   3.4. Resiliency....................................................8 
     
   Watkinson             Expires January 2005                       1 
                Framework for PNNI to PSN Interworking      July 2004 
    
   3.5. OAM...........................................................9 
   3.6. Summary.......................................................9 
   4. Security Considerations.........................................9 
   5. References.....................................................10 
   6. Author's Addresses.............................................11 
   7. Intellectual Property Statement................................11 
   8. Full Copyright Statement.......................................11 
   


1. Introduction 
    
1.1. Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in RFC-2119 
   [RFC2119]. 
    


1.2. Objectives and Scope of the Document 
    
   This document extends [L2VPN-FRMK] by including mechanisms for 
   interworking with attachment circuits that are ATM SPVCs. 
    
    
   Service providers are introducing new PSN based networks and are 
   looking for a seamless way to extend the reach of existing FR/ATM 
   services to new sites attached to this PSN network. One important 
   capability which is used in the existing FR/ATM networks is ATM 
   switched services. These are mainly SPVC services and to a lesser 
   extent SVC services. SPVC services are critical in today╦s networks 
   as they allow simplified provisioning of the FR/ATM services by 
   configuring the endpoints only. They also allow online traffic 
   engineering and a faster restoration in the case of a network 
   failure. Finally, ATM SPVCs extend connectivity to non-ATM endpoints 
   such as FR and Ethernet endpoint on an ATM switch. They are thus 
   used in both network and service interworking deployment scenarios. 
   It is therefore important to provide methods for interworking ATM 
   switched services and PSN based services such as VPWS. 
    
   There are two models that must be considered when ATM SPVCs are 
   attachment circuits.  The first model has both attachment circuits 
   of the connection using the ATM signaling for connection 
   establishment.  The second model has only one of the attachment 
   circuits of the connection using ATM signaling and the other 
   attachment circuit using a different access technology (switched or 
   permanent).  
    
    
   It must be emphasized that both models are likely to exist within 
   the same network.  Some connections may be ATM signaling to ATM 
   signaling.  Other connections may be ATM signaling to a non-switched 


     
   Watkinson             Expires January 2005                       2 
                Framework for PNNI to PSN Interworking      July 2004 
    
   AC.  There also will be standard VPWS services connecting two non-
   signaled AC╦s together. 
    
   There are no methods to signal port connections in ATM thus there is 
   no intent to provide PW services for transporting an entire ATM port 
   across the PSN using these services.  These PW services should use 
   standard VPWS services instead.  This may include the tunneling of 
   many VC╦s including PNNI RCC and Signaling links within the same 
   port pseudowire.  There are no interactions between PNNI and the PSN 
   in these networks, thus there are no protocol considerations. 
    


2. ATM Signaled to PSN to ATM Signaled Networks 


    
              ACs                 PSN                ACs 
           Signalled             Tunnel           Signalled 
              ATM                                    ATM 
                    +------+              +------+ 
      +-----+       |  PE1 |==============| PE2  |        +-----+ 
      | CE1 |-----------.........PW..........-------------| CE2 | 
      +-----+       | VPWS |              | VPWS |        +-----+ 
                    |      |==============|      | 
                    +------+              +------+ 
    
                               Figure 1 
    
   The AC╦s can be ATM UNI╦s for the operation of SVC services over the 
   network or any other AC type that has an interworking function with 
   ATM.  Examples include non-signaled ATM, Frame Relay and Ethernet.  
   These are supported through SPVC services. 
    
   The SVC services start and terminate on the CE devices.  The 
   signaling for the SPVC services start and terminate on the adjacent 
   ATM switches to the CE╦s. 
    
   The intention is to provide service over a PSN without impacting the 
   ATM signaling that occurs between the CE devices.  PE1 and PE2 may 
   have additional procedures and there may be changes to signaling 
   between PE1 and PE2 but no other nodes are affected by these 
   procedures. 
    
   The three mechanisms that will be discussed are [PNNI-VPN] and 
   Virtual Trunking which tunnel PNNI Routing and Signaling and the 
   [DRAFT-METZ] which interworks both PNNI Routing and Signaling to 
   PSN/PW Routing and Signaling protocols. 
    
   The comparison of Virtual Trunking / [PNNI-VPN] and [DRAFT-METZ] 
   will be left for a future version of this draft if it is felt to be 
   necessary.  See [PNNI-VPN] for more details of this solution.  It is 
   structured similarly to the framework described below in section 3. 
    
   Virtual Trunking emulates an ATM port or VP carrying many 
   connections using a PW.  [PNNI-VPN] emulates a single ATM VP or ATM 
     
   Watkinson             Expires January 2005                       3 
                Framework for PNNI to PSN Interworking      July 2004 
    
   VC using a PW.  They both use PNNI routing and signaling for each 
   individual customer connection. 
    
   The advantages of Virtual Trunking are: 
   a) No changes are required to the PNNI protocol. 
   b) No requirement to combine ATM and MPLS Control Planes on the same 
      equipment.  This can be a two-box solution. 
   c) Only one PW is signalled instead of two PW for the PNNI RCC and 
      Signaling channels. 
    
   The advantages of [PNNI-VPN] are: 
   a) Improved data efficiency when ATM 1:1 cell mode is used with 
      [PNNI-VPN]. 
   b) Improved QoS support.  A single ATM connection has a given SLA.  
      This is more easily mapped into the QoS capabilities that are 
      provided with the PW label.  With Virtual Trunking, a port 
      carrying many connections will have a mix of QoS capabilities 
      that will need to be emulated over the single PW. 
   c) Improved traffic engineering using separate admission control of 
      each customer connection on to an MPLS tunnel instead of the 
      coarse control of the emulated ports. 
   d) Less provisioning.  The characteristics of each emulated ATM port 
      or VP need to be configured including their bandwidths. 
   e) Better failure recovery.  A failure of a single PW will only 
      affect one connection with [PNNI-VPN].  PNNI rerouting can 
      quickly restore this individual connection.  A single PW failure 
      with Virtual Trunking will cause many PNNI connections to be 
      rerouted. 
   f) Unknown OAM treatment for Virtual Trunks.  When a pseudowire 
      fails, it is unknown how many VPI╦s are being tunneled, thus how 
      many F4 AIS cells are required to be generated. 
    
   The choice of Virtual Trunking vs. [PNNI-VPN] will depend solely 
   based on an evaluation of the advantages of each listed above as 
   they both provide the same service. 




















     
   Watkinson             Expires January 2005                       4 
                Framework for PNNI to PSN Interworking      July 2004 
    


3. ATM Signaled to PSN Networks 
                                         Non-signaled 
          Attachment        PSN           Attachment 
           Circuits        tunnel          Circuits 
          Signalled          + 
   +-----+   ATM           pseudo                  +-----+ 
   |     |                  wire                   |     | 
   | CE1 +---+                                 +---| CE2 | 
   |     |   |   +-----+   +-----+   +-----+   |   |     | 
   +-----+   +---+---- |   |  P  |   | ----+---+   +-----+ 
                 |VPWS\|---|-----|---|/VPWS| 
                 | PE1 |===|=====|===| PE2 | 
   +-----+       |    /|---|-----|---|\    |       +-----+ 
   |     |   +---+---- |   |     |   | ----|---+   |     | 
   | CE3 +---+   +-----+   +-----+   +-----+   +---+ CE4 | 
   |     |                                         |     | 
   +-----+                                         +-----+ 
                
                               Figure 4 
    
    
   This network shows one side of the PSN as explained in the section 
   above.  Again, this can be PNNI, AINI, or UNI.  The other side does 
   not use ATM signaling.  Any AC as defined in [L2VPN-FRMK] can be 
   used in this network.  The desire in this network scenario is to 
   avoid any changes in the ATM signaling that occurs up to PE1 and to 
   avoid any changes in the PSN signaling that occurs through the PSN 
   up to PE2.  There may be minor changes to the procedures on PE2.  
   The only node affected by these procedures is PE1.  There is no 
   signaling between PE2 and CE2 or CE4.  No configuration is needed on 
   PE1 to perform the interworking. 
    
    
3.1. Signaling and Routing 
    
   There are two possible directions for single-sided call setup in 
   these networks.  The SPVC calls can start from CE1 or CE3 or the ATM 
   switch CE1 or CE3 is attached to.  The calls will be converted from 
   ATM signaling to an appropriate pseudowire signaling. 
    
   In these network situations, there is no point in communicating any 
   of the ATM signaled parameters to PE2.  PE2 may not even be able to 
   handle or deal with these parameters.  PE1 needs to interwork as 
   many of the ATM parameters into equivalent pseudowire signaling.  
   Some of the mechanisms to do this are discussed in [PWE3-SPVC-IW]. 
    
   Alternatively, calls can start from PE2 as pseudowire signaling and 
   be converted to ATM signaling.  This suffers from some of the same 
   drawbacks as encountered in [DRAFT-METZ].  The major one is the 
   desire to signal ATM traffic parameters through the ATM network. 


   The first of these mechanisms is more appropriate as the ATM 
   signaling provides sufficient information to generate the pseudowire 
     
   Watkinson             Expires January 2005                       5 
                Framework for PNNI to PSN Interworking      July 2004 
    
   signaling but the pseudowire signaling is missing information that 
   may be important to the ATM network operator such as the ATM traffic 
   parameters. 
    
   When the call setup direction is CE1 or CE3 (or from the ATM switch 
   CE1 or CE3 is attached to) towards PE2, reachability needs to be 
   communicated from the PSN to the ATM network.  The easiest 
   translation of addressing is using IPv4/IPv6 addresses in the PSN 
   and ATM End System Addresses (AESA) embedded IPv4/IPv6 addresses 
   within the ATM network [ATM-IP-ADDR].  PE1 needs to advertise all of 
   the IPv4/IPv6 addresses of the other PE nodes into PNNI.  One 
   mechanism is to advertise them as exterior reachable addresses.  
   Other mechanisms are for future study. 
    
   When the call setup direction is from PE2, ATM reachability needs to 
   be advertised into a PSN routing protocol.  This would most likely 
   be MP-BGP. 
    
   Only SPVC services are supported.  Note that SPVC services can be 
   extended across the ATM UNI using the UNI signaling SPVC IE as 
   defined in [ATM-UNI-41]. 
    
   Due to the additional requirements placed on pseudowire signaling 
   and the existing protocol support of advertising IP reachability 
   into ATM, the best choice is signaling from CE1 or CE3 towards PE2 
   and the insertion of IP routes into PNNI.  The initiation of 
   signaling from PE2 and advertising of ATM reachability into MP-BGP 
   will be left as a topic for future discussion. 
    
    
3.2. Data Format 
    
   It is possible to use many of the PW types for the transmission of 
   the data through the PSN.  For example, if it is known through the 
   ATM signaled parameters that all traffic is RFC2684 Bridged, it is 
   possible to use an Ethernet PW type.   
    The following are the various endpoint interworking scenarios and 
   the valid PW types to use. By default, the ATM-PSN gateway selects a 
   ATM PW unless otherwise specified. 
    
   a. ATM-ATM endpoints:  
    
   Configure a ATM PW which uses any of the encaps in [draft-pwe3-atm-
   encap]. The ATM PW encapsulation type is negotiated between the ATM-
   PSN gateway and PE2 during the PW setup. 
    
   b. ATM-FR endpoints:  
    
   Two scenarios are possible. The first one is to configure a FR PW 
   and perform FRF.8.1 [FRF.8.1] in ATM-PSN gateway. ATM-PSN gateway 
   selects a FR PW type after inspecting TBD in the received ATM call 
   setup message. 



     
   Watkinson             Expires January 2005                       6 
                Framework for PNNI to PSN Interworking      July 2004 
    
   The second one is to configure a ATM PW and perform FRF.8.1 in PE2. 
   ATM Encapsulation type negotiated between the ATM-PSN gateway and 
   PE2. ATM-PSN gateway can select the AAL5 PDU or SDU encapsulations 
   after inspecting TBD in the received ATM setup message. 
               
   c. FR-FR endpoints: 
     
   Two scenarios are possible. The first one is to configure a FR PW 
   and perform FRF.5 [FRF.5] in ATM-PSN gateway. The ATM-PSN gateway 
   selects a FR PW type after inspecting TBD in the received ATM call 
   setup message. 
    
   The second one is to configure a ATM PW and perform FRF.5 in PE2. 
   ATM Encapsulation type negotiated between the ATM-PSN gateway and 
   PE2. ATM-PSN gateway can select the AAL5 PDU or SDU encapsulations 
   after inspecting TBD in the received ATM setup message. 
    
   d. (FR/ATM)-Ethernet endpoints:  
    
   Three scenarios are possible. The ATM-PSN gateway selects the 
   appropriate PW encapsulation type after inspecting TBD in the 
   received ATM call setup message. 
   The first one is to configure a IP PW for IP only connections. 
    
   The second one is to configure an Ethernet PW for Ethernet only 
   connections. 
    
   The last one is to configure multiple parallel PWs [L2VPN-IW] or a 
   multiprotocol PW [EXTENDED-PID] for the multiprotocol connection 
   case. 
    
   In many ATM signaled networks, there will not be the necessary 
   parameters to determine the above interworking schemes without pre-
   configuration of all of the possible gateway nodes.  The gateway 
   node will be required to choose either the ATM N:1 VC Cell Mode with 
   the cell concatenation that is supported.  When PE2 does not support 
   either of these PW Types, negotiation of the PW Type can take place.  
   Procedures for this are TBD. 
    
   OAM is a consideration as referred to below in section 3.6.   
    


3.3. QoS 
    
   The ATM traffic parameters can be converted into traffic parameters 
   for use on the pseudowire.  Specifically, admission control of the 
   PW into the appropriate PSN tunnel in both the ATM-PSN gateway and 
   PE2 requires the knowledge of the PW traffic descriptor. Appropriate 
   translation needs to be defined to map ATM traffic parameters to 
   [PWE3-CP-EXT] or other equivalent mechanisms to signal pseudowire 
   QoS parameters.  The overhead based on the PW type needs to taken 
   into account. 
    
    
     
   Watkinson             Expires January 2005                       7 
                Framework for PNNI to PSN Interworking      July 2004 
    
3.4. Resiliency 
    
 3.4.1. Dual-Homing of ATM Network to PSN 
    
          Attachment         PSN           Attachment 
           Circuits         tunnel          Circuits 
          Signalled           + 
   +-----+   ATM            pseudo                  +-----+ 
   |     |                   wire                   |     | 
   | CE1 +---+                                  +---| CE2 | 
   |     |   |   +-----+   +------+   +-----+   |   |     | 
   +-----+   +---+---- |   |  P   |   | ----+---+   +-----+ 
                 |VPWS\|---|------|---|/VPWS| 
                 | PE1 |===|======|===| PE2 | 
   +-----+       |    /|---|------|---|\    |       +-----+ 
   |     |   +---+---- |   |------|---| ----|---+   |     | 
   | CE3 +---+   +-----+  /|------|---|     |   +---+ CE4 | 
   |     |       +-----+ //+------+   +-----+       |     | 
   +-----+       |     |//                          +-----+ 
                 |     |/ 
                 |VPWS | 
                 | PE3 | 
                 +-----+ 
                               Figure 5 
    
   Multiple PE nodes can exist between the PSN and the ATM network.  
   Each of these PE nodes will advertise reachability to the AESA 
   embedded IPv4/IPv6 addresses.  In the ATM network, these addresses 
   will be considered multi-homed addresses.  When a tunnel from one PE 
   node (e.g. PE1) to another (e.g. PE2) fails, the PE node should no 
   longer advertise reachability.  This will allow the alternate PE3 
   node to take over. 
    
    





















     
   Watkinson             Expires January 2005                       8 
                Framework for PNNI to PSN Interworking      July 2004 
    
 3.4.2. Mutlihop Tunnel Routing over the PSN 
    
          Attachment         PSN           Attachment 
           Circuits         tunnel          Circuits 
          Signalled           + 
   +-----+   ATM            pseudo                  +-----+ 
   |     |                   wire                   |     | 
   | CE1 +---+                                  +---| CE2 | 
   |     |   |   +-----+     ----     +-----+   |   |     | 
   +-----+   +---+---- |    /PSN \    | ----+---+   +-----+ 
                 |VPWS\|---|------|---|/VPWS| 
                 | PE1 |===|======|===| PE2 | 
   +-----+       |    /|---|------|---|\    |       +-----+ 
   |     |   +---+---- |---|\    /|---| ----|---+   |     | 
   | CE3 +---+   |     |---|\\  //|---|     |   +---+ CE4 | 
   |     |       +-----+    ------    +-----+       |     | 
   +-----+                  ||  ||                  +-----+ 
                           +------+ 
                           | VPWS | 
                           |  PE3 | 
                           +------+ 
    
                           Figure 6 
    
   In the absence of any direct tunnel to the desired PE node, the use 
   of multiple hops as shown in Figure 6 is TBD.  The use of splicing 
   of pseudowires is discussed in [L2VPN-SIG] but only for use in 
   Distributed VPLS. 
    
    
3.5. OAM 
    
   The handling of OAM depends on the type of endpoint interworking, as 
   explained in [VPWS-IW-OAM].  
    


3.6. Summary 
    
   The direction of call setup from ATM to PSN is the preferred model.  
   Call setup from PSN to ATM will remain as future work item. 



4. Security Considerations 


   Additional security issues exist on top of those that are discussed 
   in [L2VPN-FRMK]. 
    
   There are security issues that apply to control access to the PSN by 
   ATM SPVC users within the access network.  PE1 may need access 
   control procedures for ATM SPVC users when performing these 
   procedures. 
    
    


     
   Watkinson             Expires January 2005                       9 
                Framework for PNNI to PSN Interworking      July 2004 
    
5. References 
    
   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
      Requirement Levels", BCP 14, RFC 2119, March 1997. 
    
   [DRAFT-METZ] Metz, C., čSwitched ATM L2VPN¸, draft-metz-switched-
      atm-l2vpn, June 2003. 
    
   [L2TP] Townsley, W. M. et. al., čFrame-Relay Pseudo-Wire Extensions 
      for L2TP¸, draft-ietf-l2tpext-pwe3-fr-02.txt, June 2003. 
                                                                         
   [L2VPN-FRMK] Andersson, L. et. al., "L2VPN Framework", draft-ietf-
      l2vpn-l2-framework-03.txt, October 2003. 
    
   [ATM-MPLS-v2] ATM Forum, čATM-MPLS Network Interworking, version 
      2.0¸, af-aic-0178.001, August 2003. 
    
   [PNNI-VPN] Bocci, M. et. Al., čSignalling Interworking for ATM 
      Pseudo Wires¸, draft-bocci-pnni-vpn-00.txt, February 2004. 


   [PWE3-SPVC-IW] Swallow, G. et. al., čSoft Permanent Virtual Circuit 
      Interworking between PWE3 and ATM¸, draft-swallow-pwe3-spvc-iw-
      00.txt, October 2003. 
    
   [ATM-UNI-41] ATM Forum, čATM User-Network Interface Signalling 
      Specification, Version 4.1¸, af-sig-0061.002, April 2002. 
    
   [L2VPN-IW]  Sajassi, A., et al., čL2VPN Interworking¸, draft-
      sajassi-l2vpn-interworking-01.txt, March 2003. 
    
   [EXTENDED-PID] Aissaoui, M., et al., čExtended MPLS/PW PID¸, draft-
      aissaoui-extended-pid-01.txt, October 2003. 
    
   [PWE3-CP-EXT] Shah, M. et. al., čDynamic Parameters Signaling for 
      MPLS-based Pseudowires¸, draft-shah-pwe3-control-protocol-
      extension-01.txt, June 2003. 
    
   [L2VPN-SIG] Rosen, E. et. al., čProvisioning Models and Endpoint 
      Identifiers in L2VPN Signaling¸, draft-rosen-ppvpn-l2-signaling-
      03.txt, May 2003. 
    
   [FRF.8.1] Frame Relay Forum, čFrame Relay / ATM PVC Service 
      Interworking Implementation Agreement¸, FRF.8.1, February 2000. 
    
   [FRF.5] Frame Relay Forum, čFRF Frame Relay/ATM PVC Network 
      Interworking Implementation Agreement¸, FRF.5, December 1994. 
    
   [PWE3-CONTROL] Martini, L., et al., čPseudowire Setup and 
      Maintenance using LDP¸, draft-ietf-pwe3-control-protocol-04.txt, 
      October 2003. 
    
    [VPWS-IW-OAM] Aissaoui, M., et al., "OAM Procedures for VPWS 
      Interworking¸, draft-aissaoui-l2vpn-vpws-iw-oam-00.txt, February 
      2004. 
     
   Watkinson             Expires January 2005                      10 
                Framework for PNNI to PSN Interworking      July 2004 
    
    


6. Author's Addresses 
    
   David Watkinson 
   Alcatel 
   Phone:  +1 613 7846847 
   Email:  david.watkinson@alcatel.com 
    
   Mustapha Aissaoui 
   Alcatel 
   Phone:  +1 613 7846912 
   Email:  mustapha.aissaoui@alcatel.com 
    
   Matthew Bocci 
   Alcatel 
   Phone: +44 20 8883 2782 
   Email: matthew.bocci@alcatel.co.uk 
    
    
7. Intellectual Property Statement 


   The IETF takes no position regarding the validity or scope of any 
   intellectual property 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; neither does it represent that it 
   has made any effort to identify any such rights. Information on the 
   IETF's procedures with respect to rights in standards-track and 
   standards-related documentation can be found in BCP-11. Copies of 
   claims of rights made available for publication 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 implementors or users of this specification 
   can be obtained from the IETF Secretariat. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights which may cover technology that may be required to practice 
   this standard. Please address the information to the IETF Executive 
   Director. 



8. Full Copyright Statement 
    
   "Copyright (C) The Internet Society (2004). Except as set forth 
   below, authors retain all their rights. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  However, this 
     
   Watkinson             Expires January 2005                      11 
                Framework for PNNI to PSN Interworking      July 2004 
    
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   rights in submissions defined in the IETF Standards Process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 
   REPRESENTS (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. 





































     
   Watkinson             Expires January 2005                      12