Internet DRAFT - draft-wang-mpls-rsvp-te

draft-wang-mpls-rsvp-te






Network Working Group                                       D. Wang, Ed.
Internet-Draft                                              Y. Peng, Ed.
Intended status: Standards Track                                   UESTC
Expires: July 13, 2010                                   January 9, 2010


  Extension to RSVP-TE for signaling control of dynamic Hose-based VPN
                     draft-wang-mpls-rsvp-te-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 July 13, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Wang & Peng               Expires July 13, 2010                 [Page 1]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Abstract

   This document describes the extension to resource reservation
   protocol-traffic engineering for signaling control of dynamic Hose-
   based VPN.  The signaling procedure is used to achieve dynamic
   revision of hose interface.  This document proposes a new Hose-Notify
   message and a series of signaling procedure for extension of RSVP-TE
   to achieve this function.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5

   4.  Hose-Notify message  . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Introduction of Hose-Notify message  . . . . . . . . . . .  6
     4.2.  VPN_Request Object . . . . . . . . . . . . . . . . . . . .  6
     4.3.  VPN_Response Object  . . . . . . . . . . . . . . . . . . .  8
       4.3.1.  VPN_ACK Object . . . . . . . . . . . . . . . . . . . .  8
       4.3.2.  VPN_NACK Object  . . . . . . . . . . . . . . . . . . .  9
       4.3.3.  Rerouting_ACK Object . . . . . . . . . . . . . . . . . 11
     4.4.  Hose_Resizing Object . . . . . . . . . . . . . . . . . . . 12
     4.5.  Net_Inf_Notify Object  . . . . . . . . . . . . . . . . . . 13
     4.6.  Hose state block (HSB) . . . . . . . . . . . . . . . . . . 14
     4.7.  Network state block (NSB)  . . . . . . . . . . . . . . . . 15

   5.  Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 15
     5.1.  VPN Connection Establishment . . . . . . . . . . . . . . . 15
     5.2.  Hose Resizing and Routing update procedure . . . . . . . . 16
     5.3.  Notification of Network Information  . . . . . . . . . . . 17
     5.4.  Resv message Failure for insufficient network resources  . 18

   6.  Update Message object of RSVP-TE . . . . . . . . . . . . . . . 19
     6.1.  Extension of sender template . . . . . . . . . . . . . . . 19
     6.2.  Extension for Filter Specification Object  . . . . . . . . 20
     6.3.  Extension for Explicit Route Object  . . . . . . . . . . . 21
     6.4.  Extension for Error Code . . . . . . . . . . . . . . . . . 22

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
     8.1.  New message Type . . . . . . . . . . . . . . . . . . . . . 22
     8.2.  New Class Numbers  . . . . . . . . . . . . . . . . . . . . 23
     8.3.  New Object Types . . . . . . . . . . . . . . . . . . . . . 23
     8.4.  New Error Code . . . . . . . . . . . . . . . . . . . . . . 24



Wang & Peng               Expires July 13, 2010                 [Page 2]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 24

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     10.2. Informative References . . . . . . . . . . . . . . . . . . 25

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25












































Wang & Peng               Expires July 13, 2010                 [Page 3]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


1.  Introduction

   To solve the resource provisioning in virtual private networks
   (VPNs), two interface models are defined.  One is the pipe model, and
   the other is the hose model [Duf1999].  Compared with pipe model,
   hose model provides important advantages to a VPN.  It is easy to
   specify QoS requests from customer since only one inward and outward
   rate per hose endpoint needs to be specified.  It also provides
   flexibility by allowing packets to and from a given hose endpoint to
   be distributed arbitrarily over other endpoints.  Statistical
   multiplexing gains can also be achieved on hose rate aggregation.
   And the requirements are easier to be characterized because the
   statistical variability of each pipe is smoothed by aggregating into
   hoses.

   Section 3 of [Duf1999] describes a Dynamically Resized VPNs, in which
   online measurements are used to determine the capacity requirements
   of hoses and then the amount of resources are reserved dynamically
   adapting to such measurements.  To accommodate the above
   requirements, methods for traffic measuring and signaling protocols
   for dynamically reserving resources are required.  [Duf1999] only
   gave the method for prediction of traffic rates, and no signaling
   protocol was mentioned.  The new features described in this document
   are focusing on signaling protocol scenario for dynamically resized
   VPNs.

   RSVP-TE is a protocol used to establish label-switched paths (LSPs)
   with traffic engineering in MPLS (Multi-Protocol Label Switching).
   The capability of RSVP-TE on supporting explicit routing facilitates
   constructing a dynamically resizable VPN.  The optimal VPN tunnels
   can be renewed just through simply changing the explicit route
   object.

   The signaling protocol discussed in this document is used to achieve
   the dynamically resizable VPN, including the resizable hose interface
   at customer side and the changeable explicit routing.  To complete
   these function, some additional objects and a new message are
   proposed in the document.  And some related RSVP-TE objects are also
   redefined.

   The purpose of this document is to describe extensions of RSVP-TE to
   realize dynamically resizable VPN.  All the associated objects,
   package format, and signaling procedures for interoperation between
   customer edge (CE) and provider edge (PE), are described in detail.

   All objects and messages described in this document are optional,
   i.e., RSVP-TE can still work on its basic functions without these
   objects and messages.



Wang & Peng               Expires July 13, 2010                 [Page 4]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   All the CEs and PEs participate in a multicast group via IGMP
   [RFC2236], and all the messages are transmitted and received by group
   package.


2.  Terminology

   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 [RFC2119] This
   document uses terminologies defined in RFC2205 [RFC2205],RFC3209
   [RFC3209],RFC2236 [RFC2236] The reader is assumed to be familiar with
   the terminology in RFC3209 [RFC3209]


3.  Overview

   This document defines extensions to RSVP-TE protocol as signaling to
   establish a user-controlled dynamic hose-based VPN.  This document
   relies on the semantics of RSVP-TE for building hose LSPs and
   explicit routing.

   This document describes a new message which contains four new
   objects.  The new message, termed as Hose-Notify message, has several
   functions including VPN connection request, Notification of hose
   model resizing, and notification of network information changed.

   To perform the signaling procedure of dynamic hose-based VPN, some of
   the RSVP-TE message objects, such as sender template object, filter
   specification object, explicit routing object, and extension of Error
   Code, are revised.

   In this document, Custom Edges (CEs) resize the hose interface via
   prediction on local traffic, and Provider Edges (PEs) renew the
   optimal routing by calculating the explicit routing.  Nevertheless,
   explicit routing calculation aspects for optimal routing and local
   traffic prediction are outside of scope of this document.

   Specifically, the extensions described in this draft include the
   message formats and the signaling flow chart.  The constructions for
   hose LSPs and resource reservation are completed by original RSVP-TE.


4.  Hose-Notify message







Wang & Peng               Expires July 13, 2010                 [Page 5]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


4.1.  Introduction of Hose-Notify message

   Hose-Notify message is a new message as an additional component of
   RSVP-TE for hose-based VPN.  The effect of Hose-Notify message is
   divided into two parts; one is used to complete the VPN connection
   request through hose interface, the other is used to send
   notification message whether hose interface size is changed or
   network information is changed.

   The format of Hose-Notify message is as follows:

   Hose-Notify message Type =TBD

            <Hose-Notify Message> ::=<Common Header> [ <INTEGRITY> ]
                                     <TIME VALUES>
                                     <VPN_Request>|<VPN_Response>|
                                     <Hose_Resizing>|<Net_Inf_Notify>
                                     [ <PROTECTION> ]
                                     [ <ADMIN STATUS> ]
                                     [ <POLICY DATA> ]

            <VPN_Response>::=<VPN_ACK>|<VPN_NACK>|<Rerouting_ACK>

   Among the objects of Hose-Notify message, the VPN_Request object,the
   VPN_Response object, the Hose_Resizing object and the Net_Inf_Notify
   object are additional objects for extension of RSVP-TE.The details of
   the four new objects are described in the following sections one by
   one.

4.2.  VPN_Request Object

   The VPN_Request object has the following format:



















Wang & Peng               Expires July 13, 2010                 [Page 6]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   Class=TBD C_Type=TBD


      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     |     Length    |    Hose ID    |     VPN ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Ingress Hose size       |         Egress Hose size      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         IP V4/V6 Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     IP V4/V6 Address (Continued)              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            ......                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Length |    CE Num     |    Reserved   |     Padding   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:
       See RFC3209

   Length:
       See RFC3209

   Hose ID:
       A unique 8-bit identifier used to identify hose interface in VPN,
       assigned by the management plane.

   VPN ID:
       An 8-bit identifier used to uniquely identify the VPN in the
       network, assigned by the management plane.

   Ingress Hose size:
       A 16-bit value used to indicate the size of ingress hose
       interface.

   Egress Hose size:
       A 16-bit value used to indicate the size of egress hose
       interface.

   IP V4/V6 Address:
       See [RFC3209]








Wang & Peng               Expires July 13, 2010                 [Page 7]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   Prefix Length:
       See [RFC3209]

   CE Num:
       An 8-bit value used to indicate the number of customer edges in
       VPN

   Reserved:
       See [RFC3209]

   Padding:
       See [RFC3209]

   VPN_Request object may be carried in Hose_Notify message.  It is used
   to launch construction of VPN.  Any of customer edge (CE) could send
   VPN_Request object to its peer CEs for VPN connection request.  The
   local hose information, such as hose ID, hose size, is also sent by
   this object.  The VPN ID of connection request is also indicated in
   VPN_Request object.

4.3.  VPN_Response Object

   VPN_Response object is used to response to VPN_Request object.  It
   could be divided into three classes in terms of C-Type.  They are
   VPN_ACK object, VPN_NACK object and Rerouting_ACK object.  The
   details of these objects are described below one by one.

4.3.1.  VPN_ACK Object

   The VPN_ACK object has the following format:

   Class=TBD C-Type=TBD


      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     |     Length    |    Hose ID    |     VPN ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Ingress Hose size     |          Egress Hose size     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         IP V4/V6 Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Length |     Padding   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Wang & Peng               Expires July 13, 2010                 [Page 8]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   Type:
       See RFC3209

   Length:
       See RFC3209

   Hose ID:
       An 8-bit identifier used to identify local hose interface,
       assigned by the management plane.  The hose ID must be unique in
       VPN.

   VPN ID:
       An 8-bit identifier used to uniquely identify the VPN in the
       network, assigned by the management plane.  This field must be
       the same as it in VPN_Request.

   Ingress Hose size:
       A 16-bit value used to indicate the size of local ingress hose
       interface.

   Egress Hose size:
       A 16-bit value used to indicate the size of local egress hose
       interface.

   IP V4/V6 Address:
       See [RFC3209]

   Prefix Length:
       See [RFC3209]

   Padding:
       See [RFC3209]

   VPN_ACK object is used to confirm the VPN connection request which is
   sent by the VPN_Request object from peer CE.  This object carries the
   local hose ID, the local hose size, the IP address of the interface
   and the VPN ID.

4.3.2.  VPN_NACK Object

   The VPN_NACK object has the following format:

   Class=TBD C-Type=TBD








Wang & Peng               Expires July 13, 2010                 [Page 9]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


      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     |     Length    |    Hose ID    |    VPN ID     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         IP V4/V6 Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Length |   Error Code  |    Reserved   |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:
       The Type indicates the types of the contents of IP address.
       Currently defined values are:

       *   0x01 IP V4 Address
       *   0x02 IP V6 Address

   Length:
       The Length field contains the total length of the VPN_NACK object
       in bytes, including Type and Length fields.  The Length must be
       at least 4, and must be a multiple of 4.

   Hose ID:
       An 8-bit identifier used to identify local hose interface,
       assigned by the management plane.  The hose ID must be unique in
       VPN.

   VPN ID:
       An 8-bit identifier used to uniquely identify the VPN in the
       network, assigned by the management plane.  This field must be
       the same as it in VPN_Request.

   IP V4/V6 Address:
       See [RFC3209]

   Prefix Length:
       See [RFC3209]

   Error Code:
       The Error Code field indicates the reasons for denial of the VPN
       connection request.  Error Code is set to zero if the VPN
       customer actively quits.  Currently defined values are
       illustrated in table 1.








Wang & Peng               Expires July 13, 2010                [Page 10]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


        +------------+--------------------------------------------+
        | Error Code |                   Meaning                  |
        +------------+--------------------------------------------+
        |      0     |                Actively Quit               |
        |      1     | Authentication of Policy Control is failed |
        |      2     |     Data of the object is not integrity    |
        |      3     |              Hose ID collision             |
        |      4     |              VPN ID collision              |
        +------------+--------------------------------------------+

                    Table 1: The meaning of Error Code

   Padding:
       See [RFC3209]

   VPN_NACK object is used to refuse the VPN connection request from
   peer CE or quit the VPN which already add in.

4.3.3.  Rerouting_ACK Object

   Rerouting_ACK object is used to send acknowledgement notice to
   customer edge (CE) after the successful dynamic routing update.
   Rerouting_ACK contains the VPN ID and the CE number after the routing
   update.

   The Rerouting_ACK object has the following format:

   Class=TBD C-Type=TBD


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length    |    VPN ID     |     CE Num    |    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:
       The Length field contains the total length of the Rerouting_ACK
       object in bytes.  The Length must be at least 4, and must be a
       multiple of 4.

   VPN ID:
       An 8-bit identifier used to uniquely identify the VPN in the
       network, assigned by the management plane.







Wang & Peng               Expires July 13, 2010                [Page 11]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   CE Num:
       An 8-bit value used to indicate the number of customer edges in
       VPN after the dynamic rerouting.

   Reserved:
       An 8-bit length reserved for extensions of VPN ID or CE Num.

4.4.  Hose_Resizing Object

   Hose_Resizing object is used to resize the size of hose interface.
   CE would send Hose_Resizing object to its peer-to-peer CEs when the
   size of its hose interface has changed.  Functionally, this
   Hose_Resizing object contains two aspects; Hose_Resizing object is
   used to notify the update of the local hose interface to its peer-to-
   peer CEs, which named as Active-notify function; and the CE which
   received a Hose_Resizing object send a Hose_Resizing object back for
   acknowledgement and to notify its own hose interface update, which
   named as Inactive-notify.

   The Hose_Resizing object has the following format:

   Class=TBD C-Type=TBD


      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     |     Length    |    Hose ID    |    VPN ID     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Ingress Hose size     |         Egress Hose size      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:
       The Type field indicates the type of the function.  Currently
       defined values are:

       *   0x01 Active-notify function
       *   0x02 Inactive-notify function

   This Type field is used to avoid hose update oscillation.  The CE
   received the Hose-Notify object with type 1 would send the
   Hose_Notify object back, if the Type of Hose_Notify message is 2, CE
   just receives it.








Wang & Peng               Expires July 13, 2010                [Page 12]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   Length:
       The Length field contains the total length of the Hose_Resizing
       message object in bytes.  The Length must be at least 4, and must
       be a multiple of 4.

   Hose ID:
       A unique 8-bit identifier used to identify local hose interface,
       assigned by the management plane.

   VPN ID:
       A unique 8-bit identifier used to indicate the VPN which the
       Hose_Resizing object used for.

   Ingress Hose size:
       The 16-bit field is used to indicate the updated size of the
       ingress hose interface.

   Egress Hose size:
       The 16-bit field is used to indicate the updated size of the
       egress hose interface.

4.5.  Net_Inf_Notify Object

   This object is used to notify the update contents of Network
   information.  Provider edge (PE) sends Net_Inf_Notify object to its
   Customer edges (CEs) when the network information has changed.  It
   contains the VPN ID, a series of destination Hose ID and Network
   Resource Information.

   The Net_Inf_Notify Object has the following format:

   Class=TBD C-Type=TBD


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Length    |   Des Hose ID |     ......    |    VPN ID     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Network Resource Information                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Padding    |   Padding...  |   Padding...  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Wang & Peng               Expires July 13, 2010                [Page 13]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   Length:
       The Length field contains the total length of the Net_Inf_Notify
       object in bytes.  The Length must be at least 4, and must be a
       multiple of 4.

   Des Hose ID:
       To be used as the identifiers of the destination hose interfaces.
       A provider edge (PE) could be connected with several CEs; the
       Net_Inf_Notify object may contain a series of 8-bit Des Hose ID
       field.

   VPN ID:
       A unique 8-bit identifier used to indicate the VPN which the
       Net_Inf_Notify object used for.

   Network Resource Information:
       A 4-byte field used to indicate the update contents of network
       information.  It could be used to resize the local hose interface
       by CEs.  Currently, the information contained is Maximum Network
       Bandwidth information and Minimum Network Delay information,
       which are indicated in the figure below.


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Maximum Network Bandwidth  |     Minimum Network Delay      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Padding:
       Zero on transmission.  Ignored on receipt.  This field is used to
       make sure the length of the object is a multiple of 4-byte.

4.6.  Hose state block (HSB)

   Hose state block (HSB) is used for Hose information storage.  In the
   VPN, each CE and its adjacent PE maintain HSBs for the Hose_Notify
   message.  The Hose_Notify message would store "Hose state" to HSB in
   CE node and PE node for each hose interface.  Each HSB holds hose
   state for a series of <IP Address, Hose ID, VPN ID, Ingress Hose
   size, Egress Hose size> structures as illustrated in Figure 1.  HSB
   could be used for hose resizing and explicit route calculations.


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Destination IP V4/V6 Address                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Hose ID          |             VPN ID             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Ingress Hose size      |        Egress Hose size        |



Wang & Peng               Expires July 13, 2010                [Page 14]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 1 Hose state block

4.7.  Network state block (NSB)

   Network state block (NSB) is used to maintain Network information.
   Each PE which is adjacent to VPN node maintains a Network state block
   (NSB) for the Net_Inf_Notify object.  Each NSB holds a network
   information state for a particular <Maximum network bandwidth,
   Minimum network delay> pair.  Currently, NSB maintains the following
   values obtained from a Net_Inf_Notify object:

   o  Maximum network bandwidth
   o  Minimum network delay

   NSB could be used for hose resizing and explicit route calculations.


5.  Signaling Procedures

5.1.  VPN Connection Establishment

   Figure2 indicates the signaling procedure of VPN Connection
   Establishment.  All of the CEs to be a VPN participate in a same
   multicast group with IGMP protocol [RFC2236].  The message for
   signaling transmission would be send through multicast packet.  To
   create a VPN connection, a CE node, named as source CE, sends a
   VPN_Request message object to its destination CEs.  The destination
   CEs send VPN_ACK message object to indicate the acknowledgment for
   the request.  If destination CE rejects the VPN request, VPN_NACK
   would be send.

   Path message would be send by the source CE until VPN_ACK is
   received.  However, the Path message transmission is opaque; the
   explicit route calculation would be done at source Provider Edge
   (PE).  The algorithm for explicit route calculation is not discussed
   in this document.  The source PE forwards the Path message with
   explicit route object.  As well as RSVP-TE protocol, the LSPs would
   be constructed between the source CE and destination CEs by Path and
   Resv message.  And the resources would be reserved on each LSP.
   After the VPN connection is successful, CEs in this VPN could
   communicate with these LSPs.








Wang & Peng               Expires July 13, 2010                [Page 15]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


                  Hose       Provider Network      Hose
           CE<------------> PE<------------>PE<------------>CE
            |               |               |               |
            |---VPN_Req---->|               |               |
            |               |---VPN_Req---->|               |
            |               |               |---VPN_Req---->|
    -------------------------------------------------------------------
            |               |               |<---VPN_NACK---|
            |               |<---VPN_NACK---|               |
            |<---VPN_NACK---|               |               |
    -------------------------------------------------------------------
            |               |               |<---VPN_ACK----|
            |               |<---VPN_ACK----|               |
            |<---VPN_ACK----|               |               |
            |-----path----->|               |               |
            | Explict Route/|               |               |
            |  Caculation  \|----Path------>|               |
            |               |Explict Routing|----Path------>|
            |               |               |               |
            |               |               |<-----Resv-----|
            |               |<-----Resv-----|               |
            |<-----Resv-----|               |               |
            |----Data------>|               |               |
            |               |----Data------>|               |
            |               |               |----Data------>|
            |               |               |               |

                   Figure.2 VPN Connection Establishment

5.2.  Hose Resizing and Routing update procedure

   The Hose Resizing and Routing update procedure is illustrated in
   Figure 3.  As mentioned in [Duf1999], CE could resize the local hose
   size through prediction for local traffic.  The method of prediction
   and resizing are not mentioned in this document.

   A source CE sends a Hose_Notify message to other destination CEs in
   the VPN when the local hose size has changed.  The Hose_Notify
   message shall include a Hose_Resizing object with the Type=1, which
   indicates the Hose ID and the updated hose size.  The hose resizing
   is a bi-directional procedure, destination CEs that received the
   Hose_Resizing object would resize its local hose interface and send a
   Hose_Notify message with a Type2 Hose_Resizing object back.

   The destination of the Tpye2 Hose_Resizing object is the source PE.
   Source PE re-calculates the explicit routing according to information
   from Hose_Resizing object.  The new Path message with the explicit
   route object would be sent by source PE according to the new explicit



Wang & Peng               Expires July 13, 2010                [Page 16]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   route.  After the successful interaction for the Path and the Resv
   message, the new LSPs with reserved resources would be constructed
   successfully.

   The source PE would send a Hose_Notify message contained
   Rerouting_ACK object to its adjacent source CE, this is used to
   notify the source CE that the new LSPs has been established
   successfully.


                       Hose       Provider Network      Hose
                CE<------------> PE<------------>PE<------------>CE
                 |               |               |               |
                 | Hose_Resizing |               |               |
                 |----Type=1---->| Hose_Resizing |               |
                 |               |----Type=1---->| Hose_Resizing |
                 |               |               |----Type=1---->|
                 |               |               | Hose_Resizing |
                 |               | Hose_Resizing |<----Type=2----|
                 |               |<----Type=2----|               |
                 | Explict Route/|               |               |
                 |  Caculation  \|----Path------>|               |
                 |               |Explict Routing|               |
                 |               |               |               |
                 |               |<-----Resv-----|               |
                 | Rerouting_ACK |               |               |
                 |<--------------|               |               |
                 |----Data------>|               |               |
                 |               |----Data------>|               |
                 |               |               |----Data------>|
                 |               |               |               |

            Figure.3 Hose Resizing and Routing update procedure

5.3.  Notification of Network Information

   PE sends the Hose_Notify message with the Net_Inf_Notify object to
   its adjacent CE when PE finds the update of network.  As mentioned
   before, the contents of Net_Inf_Notify object contain maximum network
   bandwidth and minimum network delay.  The width and delay information
   would used to update the Network state block, and CE would resize its
   local hose interface to adapt to the new network information.

   CE sends Hose_Resizing object to notify its adjacent PE the hose
   interface update.  The explicit route procedure is done in PE, and
   then the Path message is send with the explicit route object.  The
   Path message and the Resv message are used to reserve resources and
   renew LSPs according to the new explicit route.  If this process is



Wang & Peng               Expires July 13, 2010                [Page 17]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   successful, the Rerouting_ACK is sent to source CE similar as the
   above section.  VPN date would be transmit through the new LSPs.


                         Hose       Provider Network      Hose
                  CE<------------> PE<------------>PE<------------>CE
                   |               |               |               |
                   |Net_Inf_Notify |               |               |
          Resize  /|<--------------|               |               |
           Hose   \| Hose_Resizing |               |               |
                   |-------------->|               |               |
                   | Explict Route/|               |               |
                   |  Caculation  \|----Path------>|               |
                   |               |Explict Routing|               |
                   |               |               |               |
                   | Rerouting_ACK |<-----Resv-----|               |
                   |<--------------|               |               |
                   |----Data------>|               |               |
                   |               |----Data------>|               |
                   |               |               |----Data------>|
                   |               |               |               |

               Figure.4 Notification of Network Information

5.4.  Resv message Failure for insufficient network resources

   If the Resv message is failure because of insufficient network
   resources, the provider site where the error happened would send a
   Resv Err message to both the source CE and the destination PE.  The
   Resv Err message includes an insufficient network resources error.

   The source CE resizes its local hose interface for the insufficient
   network resources.  The resized hose size would be sent through the
   Hose_Resizing object to its adjacent PE.  PE site re-calculates the
   explicit route and sends Path message with explicit route object to
   destination PE.  The destination PE sends Resv message upstream
   towards the source CE for resource reservation.  The new LSPs have
   been established by the Path and Resv message, and the new generated
   data stream would be transmitted through these new LSPs.  Figure 5
   illustrate s the signaling procedure of Resv message failure for
   insufficient network resources.










Wang & Peng               Expires July 13, 2010                [Page 18]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


                     Hose           Provider Network          Hose
              CE<------------> PE<----------|-------->PE<------------>CE
               |               |            |         |               |
               |               |            X<--Resv--|               |
             -------------------------------|---------------------------
               |               |  Err Code  |Resv Err |               |
               |               |<-Resv-Err--|-------->|               |
               |               |            |Err Code |               |
               |               |  Insufficient Network|               |
               |               |       Resource       |               |
               |   Err Code    |            |         |               |
               |<---Resv Err---|            |         |               |
      Resize  /|               |            |         |               |
       Hose   \| Hose_Resizing |            |         |               |
               |-------------->|            |         |               |
               | Explict Route/|            |         |               |
               |  Caculation  \|-----------Path------>|               |
               |               |   Explict Routing    |               |
               |               |            |         |               |
               | Rerouting_ACK |<------------Resv-----|               |
               |<--------------|            |         |               |
               |----Data------>|            |         |               |
               |               |--------Data--------->|               |
               |               |            |         |----Data------>|
               |               |            |         |               |

     Figure.5 Resv message Failure for insufficient network resources


6.  Update Message object of RSVP-TE

6.1.  Extension of sender template

   The extended Sender_Template has the following format:

   Class=SENDER_TEMPLATE C_Type=TBD


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  IP tunnel V4/V6 Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Hose ID  |     VPN ID    |      Ingress Hose size        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Egress Hose size     |    Reserved   |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MUST be zero         |           LSP ID              |



Wang & Peng               Expires July 13, 2010                [Page 19]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP tunnel V4/V6 Address:
       See [RFC3209]

   Hose ID:
       Additional Hose ID is the Hose interface identifier for sender
       node.

   VPN ID:
       Additional VPN ID is used to indicate the VPN that the sender
       belongs to.

   Ingress Hose size:
       Additional Ingress Hose size is used to indicate the size of
       ingress hose interface.

   Egress Hose size:
       Additional Egress Hose size is used to indicate the size of
       egress hose interface.

   LSP ID:
       See [RFC3209]

6.2.  Extension for Filter Specification Object

   The extended Filter Specification has the following format:

   Class=Filter Specification C_Type=TBD


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  IP tunnel V4/V6 Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MUST be zero         |          LSP ID               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Hose ID  |    VPN ID     |    Reserved   |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP tunnel V4/V6 Address:
       See [RFC3209]








Wang & Peng               Expires July 13, 2010                [Page 20]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   LSP ID:
       See [RFC 3209]

   Hose ID:
       See the definition of Sender Template Object.

   VPN ID:
       See the definition of Sender Template Object.

6.3.  Extension for Explicit Route Object

   The extended Explicit Route Object has the following format:

   Class=Explicit Route C_Type=TBD


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|    Type     |     Length    |   Src Hose ID |  Des Hose ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       IP V4/V6 Address                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  IP V4/V6 Address (Continued)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            ......                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Prefix Length |                    Padding                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   L:
       See [RFC3209]

   Type:
       See [RFC 3209]

   Length:
       See [RFC3209]

   Src Hose ID:
       Additional Src Hose ID is used to indicate the source hose
       interface ID.

   Des Hose ID:
       Additional Des Hose ID is used to indicate the destination hose
       interface ID.





Wang & Peng               Expires July 13, 2010                [Page 21]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   IP V4/V6 Address:
       See [RFC3209]

   Prefix Length:
       See [RFC3209]

   Padding:
       See [RFC3209]

6.4.  Extension for Error Code

   The following extension Error Codes may appear in ERROR_SPEC objects
   and be passed to end system.  Except where noted, these Error Codes
   may appear only in Resv Err messages.

   Error Code=TBD: Insufficient Network Resources
       This code is reserved for the Resv message error because of the
       lack of Network resources, such as bandwidth or optical
       wavelength.

   Error Code=TBD: Unknown Hose ID
       Reservation or Path message has been rejected for the incorrect
       Hose ID.For example, the Hose ID included in Path message or Resv
       message may not correspond to the ID held in the HSB.

       This Error Code may appear in a PathErr or ResvErr message.

   Error Code=TBD: Unknown VPN ID
       Reservation or Path message has been rejected for the incorrect
       VPN ID, for example, received a Path message or Resv message came
       from other VPN, VPN ID included in Path message or Resv message
       lost through the transmission.

       This Error Code may appear in a PathErr or ResvErr message.


7.  Security Considerations

   This document does not introduce any new security issues.  The
   security issues identified in [RFC3209] are still relevant.


8.  IANA Considerations

8.1.  New message Type

   IANA is requested to assign the Type number for the new Hose-Notify
   message.



Wang & Peng               Expires July 13, 2010                [Page 22]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


8.2.  New Class Numbers

   IANA is requested to assign the Class Numbers for all the four new
   objects of Hose-Notify message, including Hose_Resquest object,
   Hose_Response object, Hose_Resizing object and Net_Inf_Notify object.
   The sub-object Types for the VPN_ACK object, VPN_NACK object and
   Rerouting_ACK object follow the same IANA considerations as
   Hose_Response object.  Suggested values for these objects are 193,
   194,195 and 196 in correct order.

8.3.  New Object Types

   IANA is requested to assign the following C-Types of some new objects
   introduced.  The C-Types for each of them are to be assigned via
   standards action.  IANA is requested to make an assignment as
   follows.

   Class name=Hose_Request
   C-Type
       Hose_Request object C-Type
   Suggested values for C-Type of Hose_Request object is 1;

   Class name=Hose_Response
   C-Type
       VPN_ACK object C-Type
   Suggested values for C-Type of VPN_ACK object is 1;

       VPN_NACK object C-Type
   Suggested values for C-Type of VPN_NACK object is 2;

       Rerouting_ACK object C-Type
   Suggested values for C-Type of Rerouting_ACK object is 3;

   Class name=Hose_Resizing
   C-Type
       Hose_Resizing object C-Type
   Suggested values for C-Type of Hose_Resizing object is 1;

   Class name=Net_Inf_Notify
   C-Type
       Net_Inf_Notify object C-Type
   Suggested values for C-Type of Net_Inf_Notify object is 1;

   Class name=SEND TEMPLATE







Wang & Peng               Expires July 13, 2010                [Page 23]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


   C-Type
       Sender Template C-Type
   Suggested values for C-Type of SEND TEMPLATE object is 9;

   Class name= Filter Specification
   C-Type
       Filter Specification C-Type
   Suggested values for C-Type of Filter Specification object is 9;

   Class name=Explicit Route
   C-Type
       Explicit Route C-Type
   Suggested values for C-Type of Explicit Route object is 2

8.4.  New Error Code

   IANA is request to assign values for the extended Error Codes as
   follows.

   Error name=Insufficient Network Resources
   Error Code
       Insufficient Network Resources Error Code
   Suggested value for Error Code of Insufficient Network Resources is
   15;

   Error name=Unknown Hose ID
   Error Code
       Unknown Hose ID Error Code
   Suggested value for Error Code of Unknown Hose ID is 16;

   Error name=Unknown VPN ID
   Error Code
       Unknown VPN ID Error Code
   Suggested value for Error Code of Unknown VPN ID is 17;


9.  Acknowledgments

   This work was supported by the National Science Fund for
   Distinguished Young Scholars of China (NSFDYS-60725104), National
   Basic Research Program of China (2007CB310706), National High
   Technology Research & Development Program of China (2007AA01Z246,
   2009AA01Z254, 2009AA01Z215).


10.  References





Wang & Peng               Expires July 13, 2010                [Page 24]

Internet-Draft      Extension to RSVP-TE for Hose VPN       January 2010


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.

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, November 1997.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

10.2.  Informative References

   [Duf1999]  N.G. Duffield, P. Goyal, A. Greenberg, P. Mishra, K.K.
              Ramakrishnan, J.E. Van der Merwe, "A flexible model for
              resource management in Virtual Private Networks", In Proc.
              ACM SIGCOMM vol29(4),pp.95-108., 1999.


Authors' Addresses

   Dong Wang (editor)
   University of Electronic Science and Technology of China
   2006 Xiyuan Road Gaoxinxiqu
   Chengdu  200240
   CN

   Phone: +86 13880432704
   Email: wangdongflower@163.com


   Yunfeng Peng (editor)
   University of Electronic Science and Technology of China
   2006 Xiyuan Road Gaoxinxiqu
   Chengdu,   200240
   CN

   Phone: +86 13880719187
   Email: yfpeng@uestc.edu.cn







Wang & Peng               Expires July 13, 2010                [Page 25]