Network Working Group                                          A. Takacs
Internet-Draft                                                   B. Gero
Intended status: Experimental                                   Ericsson
Expires: May 8, 2008                                    November 5, 2007


                 GMPLS RSVP-TE Ethernet OAM Extensions
               draft-takacs-ccamp-rsvp-te-eth-oam-ext-00

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 May 8, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Takacs & Gero              Expires May 8, 2008                  [Page 1]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


Abstract

   The GMPLS controlled Ethernet Label Switching (GELS) work is
   extending GMPLS RSVP-TE to support the establishment of Ethernet
   LSPs.  Ethernet Connectivity Fault Management (CFM) specifies an
   adjunct OAM flow to check connectivity in Ethernet networks.  CFM can
   be also used with Ethernet LSPs for fault detection and triggering
   recovery mechanisms.  This memo proposes experimental extensions to
   GMPLS RSVP-TE to support the setup of the associated CFM OAM entities
   for point-to-point bidirectional Ethernet LSPs.

   Note that the extensions defined may be applicable to other fault
   detection mechanisms that use periodic Hello messages, e.g., BFD, as
   well.  Subsequent versions of the ID will consider the possibility of
   general OAM extensions not limiting the applicability to Ethernet
   OAM.



































Takacs & Gero              Expires May 8, 2008                  [Page 2]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


Requirements Language

   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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Motivations and asumptions . . . . . . . . . . . . . . . .  4
     1.2.  Ethernet OAM operation overview  . . . . . . . . . . . . .  5
     1.3.  Scope of the extension . . . . . . . . . . . . . . . . . .  7
   2.  GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . .  8
     2.1.  Ethernet CFM TLV . . . . . . . . . . . . . . . . . . . . .  9
     2.2.  Monitoring Disabled - Admin_Status bit . . . . . . . . . . 10
     2.3.  Error handling . . . . . . . . . . . . . . . . . . . . . . 11
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17




























Takacs & Gero              Expires May 8, 2008                  [Page 3]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


1.  Introduction

   Ethernet Connectivity Fault Management (CFM) defines an adjunct
   connectivity monitoring OAM flow to check the liveliness of Ethernet
   networks [IEEE-CFM].  With Provider Backbone Bridging Traffic
   Engineering (PBB-TE) [IEEE-PBBTE] Ethernet networks will support
   explicitly-routed Ethernet connections.  CFM can be used to track the
   liveliness of PBB-TE connections and detect data plane failures.

   In IETF the GMPLS controlled Ethernet Label Switching (GELS) work is
   extending the GMPLS control plane to support the establishment of
   point-to-point PBB-TE data plane connections.  We refer to GMPLS
   established PBB-TE connections as Ethernet LSPs.  GELS enables the
   application of MPLS-TE and GMPLS provisioning and recovery features
   in Ethernet networks.

   MPLS OAM requirements are described in [RFC4377].  It provides
   requirements to create consistent OAM functionality for MPLS
   networks.  The GMPLS OAM requirements are described in [GMPLS-OAM].
   GMPLS OAM is based on the MPLS OAM requirements [RFC4377], in
   addition it also considers the existing OAM techniques in non-packet
   networks.  This memo discusses the basic aspects of Ethernet OAM and
   specifies RSVP-TE extensions addressing OAM requirements for Ethernet
   networks.

1.1.  Motivations and asumptions

   The following list is an excerpt of MPLS OAM requirements documented
   in [RFC4377].  Only a few requirements are discussed that bear a
   direct relevance to the discussion set forth in this memo and which
   also motivated the extensions specified in this document.

   1.  It is desired to support the automation of LSP defect detection.
       It is especially important in cases where large numbers of LSPs
       might be tested.

   2.  In particular some LSPs may require automated ingress-LSR to
       egress-LSR testing functionality, while others may not.

   3.  Mechanisms are required to coordinate network responses to
       defects.  Such mechanisms may include alarm suppression,
       translating defect signals at technology boundaries, and
       synchronising defect detection times by setting appropriately
       bounded detection timeframes.

   Generally, the frequency of OAM execution must be set properly, to
   achieve the OAM requirements.  When periodic messages are used for
   liveliness check of LSPs the frequency of messages must be set



Takacs & Gero              Expires May 8, 2008                  [Page 4]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


   properly fulfilling the requirements of the service and/or meeting
   the detection time boundaries posed by possible congruent
   connectivity check operations of higher layer applications.
   Furthermore, for consistent measurement of Service Level Agreements
   (SLAs) it may be required that measurement points agree on a common
   probing rate to avoid measurement problems.

   In order for Ethernet LSPs to provide reliable service delivery, data
   plane fault detection mechanisms are needed to trigger recovery
   actions.  Note that if lower layer fault detection (or protection)
   mechanisms (such as those supported by SONET/SDH) are available, we
   may rely on them and alleviate the need for frequent OAM message
   exchanges for liveliness checks of Ethernet LSPs.  However, when -
   for example - Ethernet is deployed over a WDM optical layer that does
   not provide the SONET/SDH protection characteristics, failure
   detection and recovery must be solved in the Ethernet layer.

   We assume that in networks where PBB-TE and GELS will be deployed the
   default LSP path fault detection mechanism will be based on CFM
   Connectivity Check Message (CCM) flows.

   Fast fault detection and recovery are key to reliable service
   delivery.  However, there is a trade-off between fast fault detection
   and signalling and processing overhead of connectivity monitoring
   flows.  Today, networks are providing transport of multiple service
   types each with special requirements on quality of service including
   the requirements on recovery.  To balance the tradeoff between fast
   detection and overhead it is essential that fault detection and
   recovery are matching the requirements of the supported service, as
   highlighted in [RFC3469].  For example, while business services may
   require sub-second protection switching best effort Internet traffic
   may rely on slower (in the order of seconds) restoration mechanisms.
   These different requirements are reflected in the frequency of
   connectivity monitoring packets that are needed to be exchanged over
   the Ethernet LSP supporting a particular service type.

   We assume that - for a network operator to be able to balance the
   trade-off in fast failure detection and overhead - it will be
   beneficial to configure the frequency of CCM messages on a per
   Ethernet-LSP basis.  Additionally, to simplify network management and
   reduce the risk (and impact) of misconfiguration, it is desirable to
   use Ethernet LSP signaling to configure CFM at both ends of the LSP.

1.2.  Ethernet OAM operation overview

   For the purposes of this document, we only discuss Ethernet OAM
   [IEEE-CFM] aspects that are relevant for the connectivity monitoring
   of bidirectional point-to-point PBB-TE connections.  In the



Takacs & Gero              Expires May 8, 2008                  [Page 5]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


   discussions we assume that the two directions of the bidirectional
   PBB-TE connection use the same path to allow proper operation of the
   Link Trace and Loopback Ethernet OAM functionality.

   Note that the basic operation of CFM Connectivity Check is similar to
   the operation of Bidirectional Forwarding Detection (BFD).

   At both ends of the bidiretional point-to-point PBB-TE connection one
   Maintenance Endpoint (MEP) is configured.  Each MEP is provisioned
   among others with its local VLAN ID (VID) and MAC address and the VID
   and MAC address of the remote endpoint on witch the remote MEP is
   configured.  MEPs exchange Connectivity Check Messages (CCMs)
   periodically with fixed intervals.  Eight distinct intervals are
   defined in [IEEE-CFM]:

               +---+--------------------+-----------------+
               | # | CCM Interval (CCI) | 3 bit reference |
               +---+--------------------+-----------------+
               | 0 |       No CCMs      |       000       |
               |   |                    |                 |
               | 1 |      3 1/3 ms      |       001       |
               |   |                    |                 |
               | 2 |        10 ms       |       010       |
               |   |                    |                 |
               | 3 |       100 ms       |       011       |
               |   |                    |                 |
               | 4 |         1 s        |       100       |
               |   |                    |                 |
               | 5 |        10 s        |       101       |
               |   |                    |                 |
               | 6 |        1 min       |       110       |
               |   |                    |                 |
               | 7 |       10 min       |       111       |
               +---+--------------------+-----------------+

                      Table 1: CCM interval encoding

   If 3 consecutive CCM messages are not received by one of the MEPs it
   declares a connectivity failure and signals the failure in subsequent
   CCM messages by setting the Remote Defect Indicator (RDI) bit.  If a
   MEP receives a CCM message with RDI set it immediately declares
   failure.  The detection of a failure may trigger protection switching
   mechanisms or my be signalled to a management system.  However, what
   happens once a failure is detected is out of the scope of this
   document.






Takacs & Gero              Expires May 8, 2008                  [Page 6]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


1.3.  Scope of the extension

   Although the setup of both unidirectional and bidirectional Ethernet
   LSPs is feasible, due to the symmetric bidirectional connectivity
   requirement of CFM, we only consider bidirectional point-to-point
   Ethernet LSPs.  The applicability for multipoint LSPs are for further
   study.

   The signalling of MEP identification parameters such as Maintenance
   Association name (MA name) and MEP ID is left for further study.

   Note that in addition to Connectivity Check, which is the focus of
   this memo, CFM defines Link Trace and Loopback mechanisms as well.
   The proposed extension automatically creates the MEPs and associates
   them to the LSP.  Once the MEPs are created the Link Trace and
   Loopback functionality is available for on demand OAM actions.
   Whether additional parameters besides those specified in the next
   sections are required (or are beneficial) to support Link Trace
   and/or Loopback is for further study.  In addition parameters needed
   to support measurement of Service Level Agreements (SLAs) is also
   left for further study.  Hence additional parameters may be defined
   in subsequent versions of this document.

   Note that the extensions defined may be applicable to other fault
   detection mechanisms that use periodic Hello messages, e.g., BFD, as
   well.

























Takacs & Gero              Expires May 8, 2008                  [Page 7]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


2.  GMPLS RSVP-TE Extensions

   To simplify the configuration of connectivity monitoring, when an
   Ethernet LSP is signalled the associated MEPs should be automatically
   established.  Further more, GMPLS signalling should be able to
   enable/disable connectivity monitoring of a particular Ethernet LSP.

   To configure MEPs some parameters must be provided to the Ethernet
   OAM functions.  First, the desired CCM interval must be specified by
   the management system based on service requirements or operator
   policy.  Second, the MEPs must be aware of their own and the
   reachability parameters of the remote MEP, in order CCM messages can
   be sent and received.  That is, when configuring a MEP, the CCM
   interval, local MAC address and VID over which data plane traffic and
   CCM messages are received, and the remote side MAC address and VID
   with which data plane traffic and CCM messages are sent must be
   known.

   The Ethernet Label as defined in [Fedyk-GELS] consists of the
   Destination MAC address (DA-MAC) and VID.  Hence the necessary
   reachability parameters for the MEPs can be obtained form Ethernet
   Labels.  Assuming the procedures described in [Fedyk-GELS] for
   bidirectional Ethernet LSP establishment the MEP configuration should
   be as follows.  When the RSVP-TE signalling is initiated for the
   bidirectional Ethernet LSP the local node creates the Upstream Label
   from its MAC address and locally selected VID and generates the Path
   message.  Once the remote node receives the Path message it can use
   the Upstream Label to extract the reachability information of the
   initiator.  Then it determines the MAC address and VID it would like
   to use to receive traffic.  These parameters determine the
   reachability information of the local MEP.  This in turn is used to
   construct the Ethernet Label to be put into the Resv message.  The
   only information that is missing to setup the MEP, is the CCM
   interval, which is signalled in a new TLV (the Ethernet CFM TLV) as
   specified in this memo.  Using this information the MEP can be
   configured on the node.  Once the Resv message successfully arrives
   to the initiator it can extract the remote side reachability
   information from the Ethernet Label whereby this node has also
   obtained all the information needed to establish the MEP.

   Once the MEPs are established the monitoring of the LSP is
   operational.  In certain situations, e.g., maintenance, re-
   optimisation of LSPs, it is desirable to explicitly enable or disable
   the monitoring of LSPs (i.e., start/stop exchanging CC messages).  To
   allow administrative control of LSP monitoring one bit in the
   Admin_Status object is used.  The "Monitoring Disabled" (M) bit is
   allocated for this purpose.




Takacs & Gero              Expires May 8, 2008                  [Page 8]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


   Note that since the reachability information could be extracted form
   the Ethernet Labels it is an option not using any extension to
   support MEP configuration of Ethernet LSPs.  That is, an
   implementation could use default parameters for CCM intervals to
   setup connectivity monitoring.  However, we rejected this approach,
   as it does not provide means to set the CCM interval on a per LSP
   level, leaving limited possibilities to configure CFM in a way that
   matches the supported services' requirements.  Moreover, there is no
   way for providing additional CFM parameters to configure other
   parameters of Ethernet OAM.

2.1.  Ethernet CFM TLV

   In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to
   indicate options and attributes of the LSP.  The Flags field has 8
   bits and hence is limited to differentiate only 8 options.  [RFC4420]
   defines a new object for RSVP-TE messages to allow the signalling of
   arbitrary attribute parameters making RSVP-TE easily extensible to
   support new applications.  Furthermore, [RFC4420] allows options and
   attributes that do not need to be acted on by all Label Switched
   Routers (LSRs) along the path of the LSP.  In particular, these
   options and attributes may apply only to key LSRs on the path such as
   the ingress LSR and egress LSR.  Options and attributes can be
   signalled transparently, and only examined at those points that need
   to act on them.  The LSP_ATTRIBUTES object and the
   LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC4420] to provide
   means to signal LSP attributes and options in the form of TLVs.
   Options and attributes signalled in the LSP_ATTRIBUTES object can be
   passed transparently through LSRs not supporting a particular option
   or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES
   object must be examined and processed by each LSR.  One TLV is
   defined in [RFC4420]: the Attributes Flags TLV.

   Since the extensions defined for CFM Continuity Check are required to
   be processed only by the edge nodes while internal nodes need to pass
   on the information transparently, the LSP_ATTRIBUTES object should be
   used for CFM related information signalling.

   We propose a new TLV, the Ethernet CFM TLV (depicted below) for
   supporting CFM CCM setup of Ethernet LSPs.  This new TLV accommodates
   information on CCM interval and also leaves room for further
   extensions.









Takacs & Gero              Expires May 8, 2008                  [Page 9]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type (2) (IANA)     |           Length (4)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   CI  |             Reserved (set to all 0s)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 1

   The type field indicates a new type: the Ethernet CFM TLV (2) (IANA
   to define).

   The length field is set to 4 bytes.

   CI (4 bits): CCM Interval, using the 3 bit encoding shown in Table 1.
   The first bit of the CI field is set to 0.

   The Ethernet CFM TLV is carried in the LSP_ATTRIBUTE object and is
   allowed in both the Path and Resv messages.  The CCM interval field
   in the Path message is the required value to be set for the remote
   MEPs.  The CCM interval field in the Resv message is optional and if
   present it is the CCM interval that was set by the remote MEP.  If
   the Ethernet CFM TLV is not present in the Resv message this is
   understood as the remote MEP would have been configured with the
   requested CCM interval.  The initiator upon receipt of the Resv
   message can determine whether the egress set the same interval that
   was requested or it used a different (slower) rate.  If acceptable
   the ingress may set the rate received in the Resv message otherwise
   it initiates the tear down of the LSP.  Note, both sides should use
   the same CCM interval.

   The negotiation allows accounting for the processing load posed on
   nodes to process CCM messages.  A node can consider the current CCM
   load (determined by the number of active CCM flows and their
   respective CCM intervals) when deciding to setup a new MEP with a
   given CCM interval.  It will be possible for a node to reject a small
   CCM interval request (e.g., 3.3ms) and propose a new less frequent
   rate for connectivity monitoring (e.g., 10ms).

2.2.  Monitoring Disabled - Admin_Status bit

   Administrative Status Information is carried in the Admin_Status
   object.  The Administrative Status Information is described in
   [RFC3471], the Admin_Status object is specified for RSVP-TE in
   [RFC3473].




Takacs & Gero              Expires May 8, 2008                 [Page 10]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


   One bit is allocated for the administrative control of OAM
   monitoring.  In addition to the Reflect (R) bit, 7 bits are currently
   occupied (assigned by IANA or temporarily in use by work in progress
   Internet drafts).  As the 8th bit (IANA to assign) this draft
   introduces the Monitoring Disabled (M) bit.  When this bit is set the
   connectivity monitoring of the LSP is disabled.

2.3.  Error handling

   New error messages and procedures may be needed to handle failures of
   OAM configuration.  These will be described in subsequent versions of
   this document.







































Takacs & Gero              Expires May 8, 2008                 [Page 11]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


3.  IANA Considerations

   This document specifies a new TLV, the Ethernet CFM TLV, to be
   carried in the LSP_ATTRIBUTES objects in Path and Resv messages.

   One bit (Monitoring Disabled (M)) needs to be allocated in the
   Administrative Status Object.












































Takacs & Gero              Expires May 8, 2008                 [Page 12]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


4.  Security Considerations

   The signalling of OAM related parameters and the automatic
   establishment of OAM entities introduces additional security
   considerations to those discussed in [RFC3473].  In particular, a
   network element could be overloaded, if an attacker would request
   liveliness monitoring, with frequent periodic messages, for a high
   number of LSPs, targeting a single network element.

   Security aspects will be covered in more detailed in subsequent
   versions of this document.








































Takacs & Gero              Expires May 8, 2008                 [Page 13]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


5.  Acknowledgements

   The authors would like to thank Adrian Farrel, Loa Andersson and Eric
   Gray for their useful comments.















































Takacs & Gero              Expires May 8, 2008                 [Page 14]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


6.  References

   [Fedyk-GELS]
              "GMPLS control of Ethernet", Internet Draft, work in
              progress.

   [GMPLS-OAM]
              "OAM Requirements for Generalized Multi-Protocol Label
              Switching (GMPLS) Networks", Internet Draft, work in
              progress.

   [IEEE-CFM]
              "IEEE 802.1ag, Draft Standard for Connectivity Fault
              Management",  work in progress.

   [IEEE-PBBTE]
              "IEEE 802.1Qay Draft Standard for Provider Backbone
              Bridging Traffic Engineering",  work in progress.

   [RFC3469]  "Framework for Multi-Protocol Label Switching (MPLS)-based
              Recovery", RFC 3469, February 2003.

   [RFC3471]  "Generalized Multi-Protocol Label Switching (GMPLS)
              Signaling Functional Description", RFC 3471, January 2003.

   [RFC3473]  "Generalized Multi-Protocol Label Switching (GMPLS)
              Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC4377]  "Operations and Management (OAM) Requirements for Multi-
              Protocol Label Switched (MPLS) Networks", RFC 4377,
              February 2006.

   [RFC4420]  "Encoding of Attributes for Multiprotocol Label Switching
              (MPLS) Label Switched Path (LSP) Establishment Using
              Resource ReserVation Protocol-Traffic Engineering
              (RSVP-TE)", RFC 4420, February 2006.














Takacs & Gero              Expires May 8, 2008                 [Page 15]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


Authors' Addresses

   Attila Takacs
   Ericsson
   Laborc u. 1.
   Budapest,   1037
   Hungary

   Email: attila.takacs@ericsson.com


   Balazs Gero
   Ericsson
   Laborc u. 1.
   Budapest,   1037
   Hungary

   Email: balazs.gero@ericsson.com

































Takacs & Gero              Expires May 8, 2008                 [Page 16]


Internet-Draft    GMPLS RSVP-TE Ethernet OAM Extensions    November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Takacs & Gero              Expires May 8, 2008                 [Page 17]