[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                                 M. Menth
Internet-Draft                                   University of Wuerzburg
Expires: April 27, 2009                                 October 24, 2008


 Deployment Models for PCN-Based Admission Control and Flow Termination
               Using Packet-Specific Dual Marking (PSDM)
                   draft-menth-pcn-psdm-deployment-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 April 27, 2009.


















Menth                    Expires April 27, 2009                 [Page 1]


Internet-Draft           PSDM Deployment Models             October 2008


Abstract

   This document presents different deployment models of PCN-based
   admission control (AC) and flow termination (FT) using packet-
   specific dual marking (PSDM) for encoding.  Their major is that they
   require only a single DSCP for packet marking and that they work
   reliably in the presence of ingress-egress aggregates (IEAs) with
   only a very small average number of flows.  Moreover, an advanced
   model even works with multipath routing.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Admission Control Methods  . . . . . . . . . . . . . . . . . .  7
     3.1.  Configuration of the Exhaustive Marker . . . . . . . . . .  7
     3.2.  Admission Control Based on AC States for IEAs (IEABAC)
           Using Probe Traffic  . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  Observation-Based AC for IEAs Using Probe Packets  . .  7
       3.2.2.  Congestion Level Estimate (CLE) Based AC for IEAs
               Using Probe Packets  . . . . . . . . . . . . . . . . .  8
     3.3.  Implicit per-Flow Probing  . . . . . . . . . . . . . . . .  8
       3.3.1.  A Brief Summary of RSVP  . . . . . . . . . . . . . . .  8
       3.3.2.  Modification of Standard RSVP to Perform PCN-Based
               AC . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Flow Termination Methods . . . . . . . . . . . . . . . . . . . 10
     4.1.  Configuration of the Excess Marker . . . . . . . . . . . . 10
     4.2.  Direct Measured Rate Termination (DMRT)  . . . . . . . . . 10
       4.2.1.  Operation  . . . . . . . . . . . . . . . . . . . . . . 10
       4.2.2.  Packet Dropping Policy . . . . . . . . . . . . . . . . 10
     4.3.  Indirect Measured Rate Termination (IMRT)  . . . . . . . . 10
       4.3.1.  Operation  . . . . . . . . . . . . . . . . . . . . . . 10
       4.3.2.  Required Packet Dropping Policy  . . . . . . . . . . . 10
     4.4.  Marked Flow Termination for IEAs (MFT, MFT-IEA)  . . . . . 10
       4.4.1.  Operation  . . . . . . . . . . . . . . . . . . . . . . 10
       4.4.2.  Required Packet Dropping Policy  . . . . . . . . . . . 10
   5.  Comparison with Other Deployment Models  . . . . . . . . . . . 12
     5.1.  Comparison with the Single-Marking (SM) Deployment
           Model  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  Comparison with the Control-Load (CL) Deployment Model . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 16
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17



Menth                    Expires April 27, 2009                 [Page 2]


Internet-Draft           PSDM Deployment Models             October 2008


     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20
















































Menth                    Expires April 27, 2009                 [Page 3]


Internet-Draft           PSDM Deployment Models             October 2008


1.  Introduction

   Pre-congestion notification (PCN) supports admission control (AC) and
   flow termination (FT) for high priority flows in a DiffServ region in
   order to protect the quality of service (QoS) of inelastic flows
   [PCN-arch].  PCN assumes that each link of a network is associated
   with a PCN admissible and supportable rate (AR, SR).  If its PCN
   traffic rate is below AR, the link is not pre-congested, if it is
   above AR, the link is AR-pre-congested, and if it is above SR, the
   link is SR-pre-congested.  In case of AR-pre-congestion, AC should
   block new PCN flows using this link and in case of SR-pre-congestion,
   FT should terminate sufficiently many PCN flows using this link to
   reduce the PCN rate below SR.

   Packet meter and markers on links of a so-called PCN domain mark
   packets in case of pre-congestion to notify the egress nodes about
   the highest pre-congestion level on their paths.  The egress nodes
   turn this information into AC and FT decisions.  Excess traffic
   marking marks PCN packets that exceed a certain reference rate on a
   link while exhaustive marking marks all PCN packets on a link when
   the PCN traffic rate exceeds a reference rate
   [PCN-marking-behaviour].

   The IP header has not any unused bits.  Therefore, the integration of
   the marks into the IP header is challenging.  A DSCP is chosen to
   indicate PCN and the ECN field [RFC3168] is re-used to indicate the
   exact marking.  Baseline encoding [Baseline] is able to mark packets
   as marked and unmarked and therefore it can support either excess
   traffic marking or exhaustive marking in a network.  Packet-specific
   dual marking (PSDM) [PSDM] supports two concurrent marking schemes in
   a limited way.  There are two different codepoints for unmarked
   packets (NM1, NM2) but only one codepoint for marked packets (M).
   Both baseline and PSDM encoding require only a single DSCP.  For the
   remainder of this draft we assume that packets with codepoint NM1 are
   subject to excess traffic marking packets with codepoint NM2 are
   subject to exhaustive marking.  Both marker types possibly re-mark
   these packets to M in case of AR- or SR-pre-congestion.  To determine
   the meaning of a M-marked packet, it is important to know whether it
   was NM1- or NM2-marked at the ingress node of the PCN domain.  This
   is can be achieved by introducing two types of packets: ordinary data
   packets of a PCN flow and other distinguishable signalling packets.
   These signalling packets may be associated with a flow (e.g.  RSVP
   signalling packets for that flow) or with an IEA (e.g. explicit probe
   packets to maintain its admission state).  Note that both kinds of
   probing do not require extra packets per flow and do not delay the AC
   decision.  Other encoding mechanisms are proposed that require two
   DSCPs [3state].




Menth                    Expires April 27, 2009                 [Page 4]


Internet-Draft           PSDM Deployment Models             October 2008


   This document proposes three AC methods that rely on exhaustive
   marking and three FT methods that rely on excess marking in such a
   way that PSDM can be used to encode the markings.  Basically, any of
   these AC methods can be deployed in combination with any of these FT
   methods.  The deployment of such PCN-based AC and FT has two major
   advantages compared to other deployment models [SM], [CL].

   o  They require only a single DSCP for packet marking.

   o  They work reliably even if the average number of flows per IEA is
      low.

   o  Some of them work even in case of multipath routing.

1.1.  Requirements Notation

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
































Menth                    Expires April 27, 2009                 [Page 5]


Internet-Draft           PSDM Deployment Models             October 2008


2.  Terminology

   Most of the terminology used in this document is defined in
   [PCN-arch].  The following additional terms are defined in this
   document:

   o  Exhaustive marking - generalization of threshold and ramp marking

   o  IEA - ingress-egress aggregate










































Menth                    Expires April 27, 2009                 [Page 6]


Internet-Draft           PSDM Deployment Models             October 2008


3.  Admission Control Methods

   In this section we explain three AC methods that rely on PCN feedback
   from probe packets.  We first explain the assumption on metering and
   marking and then present the AC methods.  Two of these AC methods
   maintain AC states for IEAs while the third AC method implements
   implicit probing per flow.

3.1.  Configuration of the Exhaustive Marker

   The probe packets are marked with NM2 by PCN ingress nodes to
   indicate to PCN nodes that they are subject to exhaustive marking.
   The reference rate of the exhaustive markers is set to the admissible
   rate.  It meters and marks all PCN packets and possibly re-marks NM2
   marked PCN packets to M.

3.2.  Admission Control Based on AC States for IEAs (IEABAC) Using Probe
      Traffic

   IEABAC assumes that IEA contexts are a priori set up for all IEAs for
   which PCN flows should be admitted.  An IEA context keeps an AC state
   K at the PCN ingress node of the IEA.  The AC state K may be either
   "admit" or "block".  Based on this AC state, the PCN ingress node can
   either admit or block further flows for the corresponding IEA.  To
   update the AC state according to the pre-congestion level of the path
   over which the traffic of the IEA is carried, the PCN ingress node
   sends in regular intervals extra probe messages addressed to the
   corresponding PCN egress node.  This signalling traffic is marked as
   PCN traffic with NM2 to indicate that it is subject to exhaustive
   marking.  As exhaustive marking is independent of packet sizes, the
   size of the probe packets can be chosen very small probe to minimize
   the rate of the signalling traffic.  The probe packets have a special
   format so that PCN egress nodes recognize them as such for the
   corresponding PCN ingress nodes and associate them with the correct
   IEA.  Based on the markings of the probe packets (NM2, M), the PCN
   egress node derives the new AC state for the IEA and sends and
   admission-stop or admission-continue message to the corresponding PCN
   ingress in order to update the AC state of the IEA.  In the following
   we propose two approaches for PCN egress nodes to determine the new
   AC state of an IEA.

3.2.1.  Observation-Based AC for IEAs Using Probe Packets

   When the PCN egress node receives an M-marked probe packet, it sends
   an admission-stop message to the corresponding PCN ingress node and
   sets a timer for the minimum block interval to a configurable value
   Tblock.  The timer may be reset by consecutive arrivals of M-marked
   probe packets.  When the timer expires, an admission-continue message



Menth                    Expires April 27, 2009                 [Page 7]


Internet-Draft           PSDM Deployment Models             October 2008


   is sent to the PCN ingress node.

3.2.2.  Congestion Level Estimate (CLE) Based AC for IEAs Using Probe
        Packets

   The PCN-egress-node proceeds in measurement intervals of a
   configurable time MI.  It tracks the number of missing missing probe
   packets or probe packets received with an M-mark during a measurement
   interval and at its end it calculates the CLE as the fraction of this
   number and the number of overall received and missing probe packets.
   If the CLE is smaller than a configurable value TadmCont, an
   admission-continue message is sent to the PCN ingress node.  If the
   CLE is larger than a configurable value TadmStop, an admission-stop
   message is sent to the PCN ingress node.

3.3.  Implicit per-Flow Probing

   We briefly review RSVP and explain how its signalling messages can be
   re-used for implicit per-flow probing.

3.3.1.  A Brief Summary of RSVP

   Realtime flows are usually accompanied by end-to-end signalling.  A
   popular protocol example is RSVP [RFC2205].  With RSVP, the data
   source issues a PATH message which is carried hop-by-hop over the
   same path future data packets will go.  To that end, the PATH message
   uses the same source and destination address as future data packets
   and also all other header fields that are possible input for routing
   and load balancing decisions need to be the same.  When a PATH
   message arrives at an RSVP-capable node, a PATH state is established
   pointing to the previous hop before the PATH message is forwarded
   further downstream.  When the PATH message arrives at the
   destination, the destination triggers the end-to-end reservation for
   the flow by sending a RESV message upstream along the nodes that set
   up a PATH state.  In these nodes, the RESV message is processed.  In
   particular, resource admission control is performed for the new flow
   request and if it succeeds, the node forwards the RESV message to the
   previous hop recorded by the PATH state.  This two pass signalling
   approach guarantees that the reservation is done on the downstream
   path of the future data flow.  In contrast to PATH messages, RESV
   messages have the source address of the sending node and the
   destination address of the hop pointed to by the PATH state.  That
   way, the information about the downstream next hop of the future data
   stream is conveyed to the previous hop and the flow-related
   information is stored in a RESV state.  RSVP is a soft-state
   protocol, i.e., the PATH and RESV control messages are periodically
   sent to keep the PATH and RESV states alive and, thereby, the flow
   reservations.  Admission control needs to be performed for a flow



Menth                    Expires April 27, 2009                 [Page 8]


Internet-Draft           PSDM Deployment Models             October 2008


   only once when no RESV state is set up, yet.

3.3.2.  Modification of Standard RSVP to Perform PCN-Based AC

   We assume that interior nodes of a PCN domain are RSVP-disabled.
   That means, they just forward RSVP messages without processing them
   and PCN ingress and egress nodes are neighboring RSVP-capable nodes.
   As a consequence, PCN ingress nodes decide whether new flows can be
   admitted and carried through domain or not.  When the initial PATH
   message travels downstream, it is marked with NM2 by the ingress node
   to indicate to PCN nodes that this packet is subject to exhaustive
   marking.  It is possibly re-marked to M and eventually received by
   the PCN egress node.  If no PATH state can be found for this flow at
   the PCN egress node, this PATH message is the first one and not a
   REFRESH message.  If the PATH message is the first of the flow and if
   it is marked with M, the RSVP engine sends back a PATHERR message to
   reject the flow.  If the PATH message is still marked with NM2, the
   RSVP PATH state is established at the PCN egress node and the PATH
   message is forwarded further downstream.  REFRESH messages are just
   forwarded according to standard RSVP.  When the PATH message arrives
   at the destination and a RESV message is sent back along the nodes
   with a PATH state.  Eventually, the corresponding RESV message
   arrives at the PCN ingress node.  When no RESV state is set up yet,
   this is the first RESV message and admission control must be
   performed.  By the mere fact that the RESV message arrives, the PCN
   ingress node knows that the corresponding initial PATH message was
   not marked.  Thus, it can admit any flow for which a new RESV message
   arrives.

   Note that RSVP is only an example for a two-pass end-to-end
   signalling protocol and the principle can be adopted to others.




















Menth                    Expires April 27, 2009                 [Page 9]


Internet-Draft           PSDM Deployment Models             October 2008


4.  Flow Termination Methods

   In this section we explain three FT methods that rely on PCN feedback
   from PCN data packets.  We first explain the assumption on metering
   and marking and then present the FT methods.

4.1.  Configuration of the Excess Marker

   The PCN data packets are marked with NM1 by PCN ingress nodes to
   indicate to PCN nodes that they are subject to excess marking.  The
   reference rate of the excess markers is set to the supportable rate.
   It meters all NM1-marked PCN packets and possibly re-marks them to M.
   Thus, PCN signalling traffic required for AC is not taken into
   account, but it is designed to have a low bitrate.

4.2.  Direct Measured Rate Termination (DMRT)

4.2.1.  Operation

   see [Overview]

4.2.2.  Packet Dropping Policy

   DMRT requires preferential dropping of unmarked (NM1) PCN data
   packets, otherwise the termination process can be delayed [FT-PE].

4.3.  Indirect Measured Rate Termination (IMRT)

4.3.1.  Operation

   See [Overview], same mechanism as in [CL].

4.3.2.  Required Packet Dropping Policy

   IMRT requires preferential dropping of marked (M) PCN data packets,
   otherwise significant overtermination can occur [FT-PE].

4.4.  Marked Flow Termination for IEAs (MFT, MFT-IEA)

4.4.1.  Operation

   See [MFT-PE].

4.4.2.  Required Packet Dropping Policy

   MFT-IEA works optimal when unmarked (NM1) PCN data packets are
   preferentially dropped in case of unavoidable PCN packet loss.
   However, the termination process is only little delayed without



Menth                    Expires April 27, 2009                [Page 10]


Internet-Draft           PSDM Deployment Models             October 2008


   preferential dropping of any specially marked PCN packets [MFT-PE].


















































Menth                    Expires April 27, 2009                [Page 11]


Internet-Draft           PSDM Deployment Models             October 2008


5.  Comparison with Other Deployment Models

5.1.  Comparison with the Single-Marking (SM) Deployment Model

   SM [SM] uses only a single marking scheme.  Therefore, baseline
   encoding [Baseline] can be used for PCN marking which requires also
   only a single DSCP.  However, SM uses CLE-based AC using feedback
   from data packets and as a result, it cannot block when an IEA is
   empty.  This can lead to significant overadmission [AC-PE].
   Furthermore, its termination method can lead to overtermination
   [FT-PE] even in the case of single bottlenecks [FT-PE].  Neither the
   AC nor the FT part of this method reliably workw in the presence of
   multipath routing.

5.2.  Comparison with the Control-Load (CL) Deployment Model

   CL [CL] uses two marking schemes and requires that packets can be re-
   marked to two different codepoints.  This cannot be achieved with a
   single DSCP [3state].  Spending more than a single DSCP for PCN
   encoding seems very expensive.  Therefore, the AC mechanism of CL
   should be modified, e.g. using one of the mechanisms presented in
   this document, so that a single DSCP suffices for PCN encoding.

   Like SM, CL is prone to overadmission when the number of expected
   flows per IEA is small [AC-PE].  CL's flow termination method is
   prone to overtermination in case of quickly changing traffic rates
   [FT-PE].  Neither its AC nor its FT method works with multipath
   routing.























Menth                    Expires April 27, 2009                [Page 12]


Internet-Draft           PSDM Deployment Models             October 2008


6.  IANA Considerations

   {ToDo}
















































Menth                    Expires April 27, 2009                [Page 13]


Internet-Draft           PSDM Deployment Models             October 2008


7.  Security Considerations

   {ToDo}
















































Menth                    Expires April 27, 2009                [Page 14]


Internet-Draft           PSDM Deployment Models             October 2008


8.  Conclusions

   This document presented three methods for admission control and three
   methods for flow termination.  The AC methods rely on probe packets
   which are subject to exhaustive marking and the FT methods rely on
   data packets which are subject to excess marking so that packet-
   specific dual marking (PSDM) can be used to encode PCN marks which
   requires only a single DSCP for PCN.  All AC and FT methods work with
   when the expected number of flows per ingress-aggregate is small.
   Each of the AC methods is compatible with each of the FT methods.
   One AC method and one FT method even works with multipath routing.
   Those are significant advantages compared to the deployment models
   presented in [SM], [CL].






































Menth                    Expires April 27, 2009                [Page 15]


Internet-Draft           PSDM Deployment Models             October 2008


9.  Comments Solicited

   Comments and questions are encouraged and very welcome.  They can be
   addressed to the IETF PCN working group mailing list <pcn@ietf.org>,
   and/or to the authors.














































Menth                    Expires April 27, 2009                [Page 16]


Internet-Draft           PSDM Deployment Models             October 2008


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

10.2.  Informative References

   [3state]   Moncaster, T., "A three state extended PCN encoding
              scheme", draft-moncaster-pcn-3-state-encoding-00 (work in
              progress), June 2008.

   [AC-PE]    Menth, M. and F. Lehrieder, "Applicability of PCN-Based
              Admission Control", <http://
              www3.informatik.uni-wuerzburg.de/staff/menth/Publications/
              papers/Menth08-Sub-8.pdf>.

   [Baseline]
              Moncaster, T., Briscoe, B., and M. Menth, "Baseline
              Encoding and Transport of Pre-Congestion Information",
              draft-moncaster-pcn-baseline-encoding-02 (work in
              progress), July 2008.

   [CL]       Briscoe, B., "An edge-to-edge Deployment Model for Pre-
              Congestion Notification: Admission Control over a DiffServ
              Region", draft-briscoe-tsvwg-cl-architecture-04 (work in
              progress), October 2006.

   [FT-PE]    Menth, M. and F. Lehrieder, "PCN-Based Measured Rate
              Termination", <http://www3.informatik.uni-wuerzburg.de/
              staff/menth/Publications/papers/Menth08-Sub-9.pdf>.

   [MFT-PE]   Menth, M. and F. Lehrieder, "PCN-Based Marked Flow
              Termination", <http://www3.informatik.uni-wuerzburg.de/
              staff/menth/Publications/papers/Menth08-PCN-MFT.pdf>.

   [Overview]
              Menth, M. and et al., "A Survey of PCN-Based Admission
              Control and Flow Termination", <http://



Menth                    Expires April 27, 2009                [Page 17]


Internet-Draft           PSDM Deployment Models             October 2008


              www3.informatik.uni-wuerzburg.de/staff/menth/Publications/
              papers/Menth08-PCN-Overview.pdf>.

   [PCN-arch]
              Eardley, P., "Pre-Congestion Notification Architecture",
              draft-ietf-pcn-architecture-03 (work in progress),
              February 2008.

   [PCN-marking-behaviour]
              Eardley, P., "Marking behaviour of PCN-nodes",
              draft-eardley-pcn-marking-behaviour-01 (work in progress),
              June 2008.

   [PSDM]     Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe,
              "PCN Encoding for Packet-Specific Dual Marking (PSDM)",
              Internet-Draft menth-pcn-psdm-encoding-00, June 2008.

   [SM]       Charny, A., Zhang, X., Faucheur, F., and V. Liatsos, "Pre-
              Congestion Notification Using Single Marking for Admission
              and  Termination", draft-charny-pcn-single-marking-03
              (work in progress), November 2007.






























Menth                    Expires April 27, 2009                [Page 18]


Internet-Draft           PSDM Deployment Models             October 2008


Author's Address

   Michael Menth
   University of Wuerzburg
   Am Hubland
   Wuerzburg  D-97074
   Germany

   Phone: +49-931-888-6644
   Email: menth@informatik.uni-wuerzburg.de









































Menth                    Expires April 27, 2009                [Page 19]


Internet-Draft           PSDM Deployment Models             October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.











Menth                    Expires April 27, 2009                [Page 20]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/