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

Versions: 00

Internet-Draft                                            Charles Abondo
Expires: April, 2005                              Polytechnique Montreal
                                                           Samuel Pierre
                                                  Polytechnique Montreal
                                                           October, 2004



          Hierarchical Proxy Mobile Ressource Reservation Protocol
                         draft-abondo-hmprsvp-00.txt


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.


   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 a resource reservation protocol Hierarchical
   Proxy Mobile Resource Reservation Protocol (HPMRSVP). This protocol
   is based on the hierarchical architecture HMIPv6 and used a modified
   version of FHMIPv6 to handle the handover. During a session, the
   resource reservation between two mobile nodes is limited to the
   access network. Furthermore, when a handover occurs, resources are
   uniquely reserved to the target access point before the handover is
   completed. The proposed   protocol allows to reduce delays and packet
   loss. In addition, management of refresh messages is moved to the
   access router, which holds the refresh reservation state for the
   duration of the session on behalf of the mobile unit. The access
   network thereby becomes responsible for upholding the session, which
   optimizes the utilization of the radio link.




 Abondo, Pierre                                                 [Page 1]


INTERNET DRAFT                 hpmrsvp                    October 2004




Table of Contents


   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.   Resource Reservation Procedures. . . . . . . . . . . . . . .   3
     2.1  Initial Reservation  . . . . . . . . . . . . . . . . . . .   3
     2.2  Reservation Modification . . . . . . . . . . . . . . . . .   5
   3.   Handover Procedure . . . . . . . . . . . . . . . . . . . . .   7
   4.   Refresh Procedure  . . . . . . . . . . . . . . . . . . . . .  10
   5.   References . . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.1  Normative References . . . . . . . . . . . . . . . . . . . .  11
   5.2  Informative References . . . . . . . . . . . . . . . . . . .  11
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  12
        Intellectual Property . . . . . . . . . . . .  . . . . . . .  13




1.  Introduction


  This document describes a Quality of Service (QoS) signalling protocol
  to guarantee the resource reservation in an IP-based mobile
  environment.


  HPMRSVP maintains the same messaging semantics as defined in RSVP
  [RFC2205], however, it no longer supports multicast applications but
  only unicast applications. This is a more realistic approach given
  the complexity of the reservation process with multicasting, and
  given the security issues around it. The protocol uses a simplex
  reservation process. On the contrary of RSVP, it is sender-oriented
  rather than receiver-oriented. It also keeps soft state resource
  reservation. It carries and supports all parameters for traffic and
  security control. It is based on the HMIPv6 [3] architecture and on
  the FHMIPv6 [5] protocol, however, it exclusively supports the optimal
  routing as defined in MIPv6 [2]. The main benefit is the avoidance of
  delays often caused by triangular routing.

  The MAP is used as a resource reservation proxy. Thus, it determines
  the routing of the QoS signalling messages within the access network.
  It allows to reserve resources on the behalf of a remote mobile node
  based on the session information gathered by a session initialization
  protocol (i.e. SIP).



  The routing of reservation messages in the MAP area is achieved by
  using two care-of-addresses (LCoA and RCoA). The mobile node uses a
  unique LCoA by linking the sub network identity (64 bits) to the
  presumably unique MAC address (64 bits). Consequently, this alleviates
  confusion between the Inter and Intra MAP [8] session reservations and
  it eliminates the need for the duplication address detection (DAD).



 Abondo, Pierre                                                 [Page 2]


INTERNET DRAFT                 hpmrsvp                    October 2004



  The session reservation refresh is accomplished by coordinating a
  refresh state jointly with the reservation state at the access router.
  The access router will then refresh the reservation for the duration of
  the session on behalf of the mobile node. The access network thereby
  becomes responsible for upholding the session, which optimizes the
  utilization of the radio link.


  During the handover, resource reservation between two mobiles nodes is
  limited to the access network based on layer 2 triggers. These
  mechanisms optimize the utilization of the radio link and allow to
  reduce delays and packet loss.


  HPMRSVP specifications tend to respect the signalling protocol
  requirements as defined in [4].

  This document is structured as follows. The first section outlines the
  initial and modification resource reservation procedures. The second
  section describes handover procedures while the last section is
  dedicated to the management of refresh messaging.



2.  Resource Reservation Procedures


   Each mobile has three addresses, a permanent address (HoA), a local
   care-of-address (LCoA) and a regional care-of-address (RCoA). The
   mobile node or the corresponding node is either a sender (MN_S), a
   receiver (MN_R), or both at once (MN_RS).


2.1  Initial Procedure


   The initial reservation between two corresponding nodes is restricted
   to the access network. This procedure assumes that the two mobile
   nodes do not belong to the same access network. The MN_RS sends a
   PATH message to the CN_RS. This message sets up and reserves the
   resources along the communication path to the MAP. Upon receipt of
   the message, the MAP sends a RESV confirmation message for the
   reservation on the uplink. The MAP then sends a PATH reservation
   message on behalf of the CN_RS for the reservation on the downlink.
   This assumes that the MAP is aware of the QoS requirements of the
   CN_RS. These requirements can be included at the beginning of the SIP
   session between two corresponding nodes. On the contrary of the
   protocol proposed in [8], this approach bypasses the need for the
   MN_RS to make the resource reservation on behalf of CN_RS. The later
   reservation has security issues in that the resources reserved on the
   uplink are only guaranteed by the MN_SR entity, which is not always
   trustable. It is therefore more secure that the reservation be made
   by the network rather than by the corresponding node. By this way, we
   eliminate the security issues due to none authenticate mobiles.
   Furthermore, the delays caused by end-to-end QoS signalling are
   reduced. The initial reservation procedure is shown below:


 Abondo, Pierre                                                 [Page 3]


INTERNET DRAFT                 hpmrsvp                    October 2004




                  AR        IR1        IR2        MAP
                  |          |          |          |
                  |          | (1)PATH  |          |
                --+----------+----------+--------->|
                  |          |          |          |
                  |          | (2)RESV  |          |
                <-+----------+----------+----------|
                  |          |          |          |
           MN_RS  |          |          |          |  CN_RS
                  |          | (3)PATH  |          |
                <-+----------+----------+----------|
                  |          |          |          |
                  |          | (4)RESV  |          |
                --+----------+----------+--------->|
                  |          |          |          |



                Figure 1: Initial Inter-domain reservation



   1. The MN_RS mobile node sends a PATH message to the MAP in order to
      reserve the resources on the uplink.
   2. The MAP receives the PATH message and sends a RESV message to
      confirm the resource reservation.
   3. The MAP sends a PATH message to MN_RS in order to reserve the
      resources on the downlink on behalf of the CN_RS using the CN_RS
      application and address information (HoA, RCoA, LCoA),  which are
      taken from the session opening by SIP.
   4. The MN_RS receives the PATH message and sends a RESV message to
      confirm the resource reservation.


   The advantage of this procedure is that the resource reservation is
   made locally within the access network rather than end-to-end.


   In the case where two communicating nodes belong to the same MAP
   domain, it is preferable that the initial reservation between the
   MN_RS and the CN_RS is made in an end-to-end fashion along the
   communication path. A local resource reservation using the MAP would
   be too expensive. Figure 3 shows the initial intra-domain
   reservation. The mobile node inserts the two destination addresses
   LCoA then RCoA in the MIPv6 destination header message. The presence
   of LCoA within the intermediary routersË routing tables allows for
   the messages to be sent directly to the CN_RS instead of to the MAP.


        AR1      IR1            MAP            IR2           AR2
  |     |         |              |              |             |      |
  |     |         |(1)PATH(MN->CN)              |             |      |
  |     |---------+--------------+--------------+-------------+----->|
  |     |         |              |              |             |      |


 Abondo, Pierre                                                 [Page 4]


INTERNET DRAFT                 hpmrsvp                    October 2004




  |     |         |(2)RESV(MN->CN)              |             |      |
  |     |<--------+--------------+--------------+--------------------|
  |     |         |              |              |             |      |
  |     |         |              |              |             |      |
  MN_RS |         |              |              |             |    CN_RS
  |     |         |              |              |             |      |
  |     |         |(3)PATH(CN->MN)              |             |      |
  |     |<--------+--------------+--------------+--------------------|
  |     |         |              |              |             |      |
  |     |         |(4)RESV(Cn->MN)              |             |      |
  |     |---------+--------------+--------------+------------------->|


                 Figure 2: Initial intra-domain reservation




2.2  Reservation Modification


   HMPRSVP defines a restricted local signalling in the access network.
   Nonetheless, two mobile nodes can decide to change QoS parameters
   while the session is in progress. This prompts HMPRSVP to launch a
   modification message which allows the resource reservation to be
   changed during the session. This message, identical to the PATH while
   containing a new element, is transmitted by the MAP to the CN_RS.
   Upon receipt of the message, the CN_RS sends back a RESV confirmation
   to the MN_RS. Different from what is suggested in [8], the IP-IP
   encapsulation problem in PATH messages is resolved with the
   point-to-point HMPRSVP message transmission. There is therefore no
   confusion in the interpretation of reservation messages within the
   access network.


        AR1          MAP1        B_IR        MAP2          AR2
  |     |             |           |           |             |      |
  |(1)PATHMOD(MN->CN) |(2)PATHMOD(MN->CN)     |(3)PATHMOD(MN->CN)  |
  |     |------------>+-----------+---------->+-------------+----->|
  |     |             |           |           |             |      |
  |     |             |           |           |(R1)PATH(CN->MAP2)  |
  |     |             |           |           |<------------+------|
  |     |             |           |           |             |      |
  |     |             |           |           |(R2)RESV(CN->MAP2)  |
  |     |             |           |           |-------------+----->|
 MN_RS  |             |           |           |             |      |
  |     |             |           |           |(S1)PATHMOD(MAP->CN)|
  |     |             |           |           |<------------+------|
  |     |             |           |           |             |      |
  |     |             |           |           |(S2)PATH(MAP2->CN)  |
  |     |             |           |           |-------------+----->|
  |     |             |           |           |             |      |
  |     |             |           |           | (4)RESVMOD(CN->MN) |
  |     |             |           |           |<------------+------|
 Abondo, Pierre                                                 [Page 5]


INTERNET DRAFT                 hpmrsvp                    October 2004



  |     |             |           |           |             |      |
  |     |             |           |           |             |      |
  |     |             |           |           |             |      |
  |     |             |(5)RESVMOD(CN->MN)     |             |      |
  |     |             <-----------+-----------|             |      |
  |     |             |           |           |             |      |
  |     |             |           |           |             |      |
  |(R3)PATH(MAP1->MN) |           |           |             |      |
  |<----+-------------+           |           |             |      |
  |     |             |           |           |             |      |
  |(R4)RESV(MAP1->MN) |           |           |             |   CN_RS
  |-----+------------>|           |           |             |      |
  |     |             |           |           |             |      |
  (6)RESVMOD(CN->MN)  |           |           |             |      |
  |<----+-------------+           |           |             |      |
  |     |             |           |           |             |      |
  |(S3)PATH(MN->MAP1) |           |           |             |      |
  |-----+------------>|           |           |             |      |
  |     |             |           |           |             |      |
  |(S4)RESV(MN->MAP1) |           |           |             |      |
  |<----+-------------+           |           |             |      |
  |     |             |           |           |             |      |



                 Figure 3: Reservation Modification



   The benefit of this approach is that it accounts for the MAP
   capability to interpret QoS signalling messages. As well, it resolves
   the tunnelling problem by avoiding to generate two signalling
   messages. In addition, the solution proposed in [8] splits the
   messages sent to the end of the tunnel and to the receiving entity,
   even though they are linked from a resource availability standpoint.
   It is therefore crucial to quickly confirm whether or not resources
   are available. The messaging structure during the reservation
   modification procedure is outlined in Figure 3:


   1. The MN_RS sends a PATHMOD message to the MAP1.
   2. The MAP1 transmits the PATHMOD message to the MAP2.
   3. The MAP2 routs the message to the CN_RS.


   1st Scenario: The MN_RS wants to modify the QoS parameters for the
   data packets it will receive from the CN_RS:
   R1. The CN_RS sends a PATH message to the MAP2 in order to reserve
       resources on the CN_RS uplink.







 Abondo, Pierre                                                 [Page 6]


INTERNET DRAFT                 hpmrsvp                    October 2004




   R2. Upon receipt of the PATH message, the MAP2 replies with a RESV
       message confirming that the reservation resource was successful.



   2nd Scenario: The MN_RS wants to modify the QoS parameters for the
   data packets it will send from the CN_RS:
   S1. The CN_RS sends a PATHMOD message to the MAP2 requesting that the
       MAP2 reserve resources on the CN_RS downlink.
   S2. Upon receipt of the PATHMOD message, the MAP2 sends a PATH
       message PATH to make the resource reservation.


   4. The CN_RS sends a RESVMOD message to P2 to confirm the reservation
      in the CN_RS local network.
   5. When the MAP2 receives the RESVMOD message, it transmits it to
      MAP1.



   1st Scenario: The MN_RS wants to modify the QoS parameters for the
   data packets it will receive from the CN_RS:
   R3. The MAP1 sends a PATH message to the MN_RS in order to reserve
       resources on the MN_RS downlink.
   R4. Upon receipt of the PATH message, the MN_RS replies with a RESV
       message confirming that the reservation resource was successful.


   2nd Scenario: The MN_RS wants to modify the QoS parameters for the
   data packets it will send to the CN_RS:
   6. The MAP1 sends a RESVMOD message to the MN_RS to reserve resources
      on the uplink.
   S3. The MN sends a PATH message to the MAP1 in order to reserve
       resources on the uplink.
   S4. Upon receipt of the PATH message, the MAP1 sends a RESV message
       to the MN confirming that the reservation resource was
       successful.


3. Handover Procedures


   In this section, we assume that the initial reservation between the
   MN_RS and the CN_RS was already established. In addition, the generic
   operations outlined are those related exclusively to a handover
   initiated by the mobile unit. A handover prompted by the network will
   follow the same principles. We assume that layer 2 mechanisms are
   responsible for anticipating the handover.


   The MAP holds the necessary information to support the access router
   handover located within the same HMIPv6 domain.


       PAR            MAP                    NAR
  |     |              |                      |                   |
  |  (1)SBU            |                      |                   |
  |-----+------------->|--------------------->|                   |
 Abondo, Pierre                                                 [Page 7]


INTERNET DRAFT                 hpmrsvp                    October 2004


  |     |              |                      |                   |
  |     |              | (D1)PATH(MAP->NAR)   |                   |
  |     |              |--------------------->|                   |
  |     |              |                      |                   |
  |     |              |                      |                   |
  |     |              | (D2)RESV(MAP->NAR)   |                   |
  |     |              |<---------------------|                   |
  |     |              |                      |                   |
  |     |              |                      |                   |
MN @ PAR|              | (U1)PATH(NAR->MAP)   |              MN @ NAR
  |     |              |<---------------------|                   |
  |     |              |                      |                   |
  |     |              |                      |                   |
  |     |              | (U2)RESV(NAR->MAP)   |                   |
  |     |              |--------------------->|                   |
  |     |              |                      |                   |
  |     |              |  forwarding packets  |                   |
  |     |              |=====================>|                   |
  |     |              |                      |                   |
  |     |              |                      |                   |
  |     |              |                      | (2)RS/RA messages |
  |     |              |                      |<----------------->|
  |     |              |                      |                   |
  |     |              |                      |                   |
  |     |              |                      |(3)MN packets delivered
  |     |              |                      |------------------>|
  |     |              |                      |                   |
  |     |              |  (4)LBU              |                   |
  |     |              |<---------------------+-------------------|
  |     |              |                      |                   |
  |     |              |  (5)LBACK            |                   |
  |     |              |----------------------+------------------>|
  |     |              |                      |                   |
  |     |              |  (6)Data HMIPv6      |                   |
  |     |              |<---------------------+------------------>|



                 Figure 4: Inter-domain handover without bicasting



   1st Scenario: Handover without bicasting


   1. Based on the anticipation of a layer 2 handover, the MN creates an
      NLCoA address and sends a SBU message to the MAP. The MAP forwards
      this message to the NAR. The SBU includes the NARËs NLCoA address
      information. Then, upon receipt of the SBU message, the MAP
      triggers the HPMRSVP reservation procedure.

   D1. The MAP sends a PATH message to the NAR in order to reserve
       resources on the downlink.
   D2. Upon receipt of the PATH message, the NAR sends a RESV message to
       the MAP confirming that the reservation resource was successful.
 Abondo, Pierre                                                 [Page 8]


INTERNET DRAFT                 hpmrsvp                    October 2004




   U1. The NAR sends a PATH message to the MAP to reserve resources on
       the uplink.
   U2. Upon receipt of the PATH message, the MAP sends a RESV message to
       the NAR confirming that the reservation resource was successful.


   2. The MN exchanges RS and RA messages with the NAR.
   3. When it detects that it has moved to the new link layer and
      receives the appropriate RA, the NAR delivers the buffered data
      packets to the MN via the NLCoA.
   4. The MN then follows the regular HMIPv6 operation by sending an LBU
      to the MAP. When the MAP receives the new LBU with the NLCoA from
      the MN, it will stop its transmission to the PAR and will close the
      tunnel setup to accommodate the handover.
   5. In response to the LBU, the MAP sends a LBACK to the MN and the
      procedure follows the HMIPv6 procedure.

   2nd Scenario: Handover with bicasting


   1. Based on the anticipation of a layer 2 handover, the MN sends an
      SBBU message to the MAP, which then forwards it to the NAR. The
      SBBU must include the specific NAR NLCoA address information as
      well as the bicasting information. Then, upon receipt of the SBBU
      message, the MAP triggers the HPMRSVP procedure.
   2. The MAP initiates the bicasting of the data packets to the MN at
      both the PLCoA and NLCoA addresses.
   3. The MN then follows the regular HMIPv6 operations by sending an LBU
      to the MAP. When the MAP receives the new LBU with the NLCoA from
      the MN, it will stop its transmission to the NAR and will close the
      tunnel setup to accommodate the handover.
   4. In response to the LBU, the MAP sends an LBACK to the MN and the
      remainder of the procedure follows the HMIPv6 procedure.



        PAR           MAP                  NAR
  |     |              |                    |                   |
  |  (1)SBU            |                    |                   |
  |-----+------------->|------------------->|                   |
  |     |              |                    |                   |
  |     |              | (D1)PATH(MAP->NAR) |                   |
  |     |              |------------------->|                   |
  |     |              |                    |                   |
  |     |              | (D2)RESV(MAP->NAR) |                   |
  |     |              |<-------------------|                   |
  |     |              |                    |                   |
 MN @ PAR              | (U1)PATH(NAR->MAP) |                 MN @ NAR
  |     |              |<-------------------|                   |
  |     |              |                    |                   |
  |     |              | (U2)RESV(NAR->MAP) |                   |
  |     |              |------------------->|                   |
  |     |              |                    |                   |
 Abondo, Pierre                                                 [Page 9]


INTERNET DRAFT                 hpmrsvp                    October 2004




  |     |              | (2) START BICASTING|                   |
  |<===========================================================>|
  |     |              |                    |                   |
  |     |              | (3)LBU             |                   |
  |     |              |<-------------------+-------------------|
  |     |              |                    |                   |
  |     |              | (4)LBACK           |                   |
  |     |              |--------------------+------------------>|
  |     |              |                    |                   |
  |     |              | (5)Data HMIPv6     |                   |
  |     |              |<======================================>|
  |     |              |                    |                   |
  |     |              |                    |                   |


                 Figure 5: Intra-domain handover with bicasting


4. Refresh Procedure


   The soft reservation state created in an intermediary router of the
   access network is a temporary state and thus must be refreshed all
   along the session. In RSVP [RFC2205], the corresponding nodes are
   responsible for the refresh management. This involves sending several
   signalling messages on the radio link which can cause the
   deterioration of the radio link.

   In order to resolve this issue, HPMRSVP creates a refresh state
   jointly with the reservation state at the access router level. The
   access router will support the reservation for the duration of the
   session on behalf of the mobile node. The network thereby becomes
   responsible for upholding the session, which optimizes the
   utilization of the radio link. The different objects that define
   the refresh state and the reservation state of a session are shown
   in Figure 6.



   Reservation State                       Refresh State


   Session_ID_Class:                       Session_ID_Class:
          <SESSION>                                 <SESSION>

   Service_Class:                          Flow_Specification_Class:
      <SENDER_TSPEC>                                 <TIME_VALUES>
      [FLOWSPEC]
      [<POLICY_DATA>]

   Flow_Specification_Class:               Security_Class:
       <SESSION>                                     [<INTEGRITY>]
       <SENDER_TEMPLATE>
       <TIME_VALUES>
       {<FILTER_SPEC>}
 Abondo, Pierre                                                [Page 10]


INTERNET DRAFT                 hpmrsvp                    October 2004


                    Figure 6: HPMRSVP Reservation Session


   The end of a reservation session will closed both sessionsË state. As
   a result, there are no resources wasted, neither at the network layer
   nor at the link layer.



5.  References


5.1  Normative References


   [1] Braden, R., Zhang, L., Berson,S., Herzog, S., Jamin, S.,
       ŸResource Reservation Protocol í Version 1 Functional
       Specification÷, RFC 2205, September 1997.


   [2] Johnson, D., Perkins, C., Arkko, J., ŸMobility Support in IPv6÷,
       Internet Draft, draft-ietf-mobileip-ipv6-24.txt, 30 June 2003.


   [3] Soliman H. and al., ŸHierarchical MIPv6 mobility management
       HMIPv6÷, Internet Draft, draft-ietf-mobileip-HMIPv6-07.txt,
       October 2002.


   [4] Chaskar, H., ŸRequirements of a QoS Solution for Mobile IP÷,
       Internet Draft, draft-ietf-mobileip-qos-requirements-04.txt, 30
       July 2002.


   [5] Jung, H., Koh, S., Lee, J., Soliman, H., El-Malki, K., ŸFast
       Handover for Hierarchical MIPv6 (F-HMIPv6)÷, Internet Draft,
       draft-jung-mobileip-fastho-hmipv6-01.txt, June 2003.


5.2  Informative References


   [6] Manner, J., Fu, X., ŸAnalysis of Existing Quality Service
       Signaling Protocols÷, Internet Draft, draft-ietf-nsis-signalling
       -analysis-01.txt, February 2003.


   [7] Shen, C. Q. and al., ŸMobility Extension RSVP in an RSVP-Mobile
       IPv6 Framework÷, Internet Draft, draft-shen-nsis-rsvp-mobileipv6
       -00.txt, July 2002.


   [8] Manner, J., Suihko, T., Kojo, M., Liljeberg, M., Raatikainen, K.,
       ŸLocalized RSVP÷, Internet Draft, draft-manner-lrsvp-01.txt,
       January 2003.


   [9] A. Terzis, J. Krawezyk, J. Wroclawski, L. Zhang, ŸRSVP Operation
       over IP Tunnels÷, RFC 2746, January 2000.


   [10] Westberg, L., Bader, A., Partain, D., Rexhepi, V., ŸA Proposal
        for RSVPv2-NSLP÷, Internet Draft, draft-westberg-proposal-for-
        rsvpv2-nslp-00.txt, April 2003.



 Abondo, Pierre                                                [Page 11]


INTERNET DRAFT                 hpmrsvp                    October 2004


Authors' Addresses


   Charles Abondo
   Polytechnique Montreal
   P.O Box 6079, Station Centre-ville, Montreal, Quebec
   Canada


   EMail: charles.abondo@polymtl.ca


   Samuel Pierre
   Polytechnique Montreal
   P.O Box 6079, Station Centre-ville, Montreal, Quebec
   Canada


   EMail: samuel.pierre@polymtl.ca



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.




 Abondo, Pierre                                                [Page 12]


INTERNET DRAFT                 hpmrsvp                    October 2004




Copyright Statement


   Copyright (C) The Internet Society (2004).  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.


 Abondo, Pierre                                                [Page 13]

INTERNET DRAFT                 hpmrsvp                    October 2004


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