Network Working Group H.S. Byun
Internet Draft M.J. Lee
Expires: December 2006 Ewha Womans Univ.
June 20, 2006
Extensions to P2MP RSVP-TE for Hose Model Provisioning in L3 PPVPN
draft-byun-vpn-provision-rsvp-te-00.txt
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 December 20, 2006
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes extensions to point to multipoint resource
reservation protocol traffic engineering (P2MP RSVP-TE) for hose
model based quality of service (QoS) provisioning in Layer 3 Provider
Provisioned Virtual Private Network (L3 PPVPN). This protocol enables
dynamic and automatic resource reservation according to hose-specific
or VPN-specific state provisioning, which are the resource
Byun Expires December 20, 2006 [Page 1]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
provisioning mechanisms for hose model. Protocol elements and
procedures for this solution are described.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction................................................3
2. Terminologies...............................................3
3. Overview....................................................3
4. Path Message................................................3
4.1. Path Message Format.....................................3
4.2. Path State Block (PSB)..................................3
4.3. Path Message Processing.................................3
5. Resv Message................................................3
5.1. Resv Message Format.....................................3
5.2. Resv State Block (RSBs).................................3
5.3. Reservation Style.......................................3
5.4. Resv Message Processing.................................3
6. New and Updated Message objects..............................3
6.1. VPN SENDER TEMPLATE object..............................3
6.1.1. VPN IPv4 VPN SENDER TEMPLATE object................3
6.1.2. VPN IPv6 VPN SENDER TEMPLATE object................3
6.2. VPN FILTER SPEC object..................................3
6.2.1. VPN IPv4 FILTER SPEC object........................3
6.2.2. VPN IPv6 FILTER SPEC object........................3
6.3. SUB_LABEL object........................................3
7. Security Considerations......................................3
8. IANA Considerations.........................................3
8.1. New Class Numbers.......................................3
8.2. New Class Types.........................................3
9. Acknowledgments.............................................3
10. References.................................................3
10.1. Normative References...................................3
10.2. Informative References.................................3
Author's Addresses.............................................3
Intellectual Property Statement.................................3
Disclaimer of Validity..........................................3
Copyright Statement............................................3
Acknowledgment.................................................3
Byun Expires December 20, 2006 [Page 2]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
1. Introduction
Among the standard modes of QoS in L3 PPVPN, an aggregate Customer
Edge (CE) interface level QoS ("hose" level QoS) is defined [RFC4031].
In the "hose" level QoS, sometimes also referred to as the "hose"
model, hose Service-Level Specification (SLS) just defines traffic
parameters in conjunction with the QoS objectives for traffic
exchanged between a CE and a PE (Provider Edge) for traffic destined
to a set of other sites in the VPN. In other words, the hose SLS,
defines the requirement in terms of all packets transmitted from a
given VPN site toward the service provider network on an aggregate
basis instead of the complete traffic matrix between each CE pairs.
There are several advantages to the "hose" model from a customer
perspective. Specification of VPN customer QoS requests becomes
simple. It also provides flexibility by allowing packets to and from
a given site to be distributed arbitrarily over other sites.
Customers can also obtain statistical multiplexing gains on the CE
interface level since hose rate is on an aggregate basis.
From a service provider's perspective, though, it presents more
challenging resource management problems due to the need to meet the
service level agreements (SLAs) with a very week SLS. Feasibility of
using "hose" model in practice requires for a bandwidth efficient
resource provisioning mechanism. To cope with the challenges,
resource provisioning for the "hose" model are studied extensively.
Resource provisioning for the "hose" model can be implemented in
several ways[Duf2002]. The hose-specific or VPN-specific state
provisioning mechanisms, among those provisioning mechanisms, enable
a Service Provider (SP) to make use of the hose-specific state
parameters in order to achieve resource sharing. For hose-specific
provisioning, a Hose tree that is rooted at an ingress PE of a VPN
and spanning all of the egress PEs of the VPN can be formed.
Hereinafter, we refer this hose tree as a Hose LSP. A Hose LSP is
comprised of multiple S2L sub-LSPs. The S2L Sub-LSP is the path from
the ingress PE to one specific egress PE[RFC4461]. The SP can
leverage the knowledge of hose parameters to determine the amount of
resources to be reserved on the Hose LSP. The amount of resources to
be reserved on a certain link of a Hose LSP is the minimum of ingress
hose rate and the total egress hose rate of the sites that are on the
"destination side" of the link. Note the reserved resources on the
Hose LSP are shared by all of the S2L sub-LSPs of the Hose LSP.
By taking into account the VPN-specific state parameters, further
capacity reduction can be obtained. A graph connecting all of the
ingress and/or egress sites of a VPN can be formed. Hereinafter, it
Byun Expires December 20, 2006 [Page 3]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
is referred to as a VPN tunnel. The entire hose parameters of the VPN,
i.e., the VPN-specific state parameters, are taken into account to
determine the amount of resources to be reserved on the links of this
graph. The amount of resource to be reserved on a certain link of the
graph is the minimum of the total ingress rate of the sites that are
on the "source side" of the link and the total ingress rate of the
sites that are on the "destination side" of the link. Note the
reserved resources on the graph are shared by all of the S2L sub-LSPs
of the VPN.
Yet another issue on the VPN QoS provisioning is related to applying
the above provisioning mechanisms in a real network. In order to
deploy the mechanisms in practice, a resource reservation protocol is
necessary for dynamic and automatic provisioning of networks with
hose-specific or VPN-specific state.
There exists resource reservation protocol such as [P2MP RSVP-TE],
proposed for building P2MP TE LSPs in the MPLS networks. The [P2MP
RSVP-TE] is an extended protocol of [RFC3209] for setting P2MP TE
LSPs. It is for transmission of multicast data. In the [P2MP RSVP-TE],
a P2MP LSP comprises of one or more S2L sub-LSPs starting from same
source. Also, a P2MP Tunnel comprises of one or more P2MP LSPs. The
S2L sub-LSPs belonging to a P2MP LSP can share the reserved resource
for the P2MP LSP. The way that S2L sub-LSPs of a P2MP LSP share
resources is the same as how the resources are shared by the S2L sub-
LSPs of a Hose LSP. Likewise, the S2L sub-LSPs that belong to
different P2MP LSPs and the same P2MP Tunnel can share resources
where they share hops. The way that the S2L sub-LSPs of a VPN tunnel
share the resources is the same as how the S2L sub-LSPs of a P2MP
Tunnel share the resources.
In order to deploy hose-specific or VPN-specific state provisioning,
the [P2MP RSVP-TE] can be used to set a Hose LSP or a VPN Tunnel. It
enables all of the S2L sub-LSPs belonging to the Hose LSP or the VPN
Tunnel to share resources where they share hops.
Although the [P2MP RSVP-TE] provides the setup and the resource
sharing of Hose LSPs or VPN Tunnels, it is not appropriate for hose-
specific or VPN-specific state provisioning by several reasons as
follows.
o [P2MP RSVP-TE] can not support the assignment of labels and the
label switching for transmission of unicast data. The S2L sub-LSPs
that belong to the same P2MP LSP should share labels where they
share hops. However, the hose-specific or VPN-specific state
provisioning need separate labels for each S2L sub-LSP in order to
transmit unicast data.
Byun Expires December 20, 2006 [Page 4]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
o If multiple user sites belonging to the same VPN are attached to a
single ingress PE, these SHOULD be identified from each other.
o The mechanism to compute the amount of resources to be reserved on
a link according to the hose-specific or VPN-specific state
provisioning differs from the [P2MP RSVP-TE].
Therefore, the [P2MP RSVP-TE] is not sufficient for hose-specific or
VPN-specific state provisioning.
This document describes extensions to [P2MP RSVP-TE] for hose-
specific or VPN-specific state based QoS provisioning in L3 PPVPN.
2. Terminologies
This document uses terminologies defined in [RFC4031], [RFC2205],
[RFC3209], [RFC4461], and [RFC4110]. The reader is assumed to be
familiar with the terminology in [P2MP RSVP-TE]
A Hose LSP: A set of one or more S2L sub-LSPs between the pairs of
PEs for a VPN.
A VPN Tunnel: A set of one or more Hose LSPs of a VPN.
3. Overview
This document defines extensions to [P2MP RSVP-TE] protocol to
reserve resources according to the hose-specific or VPN-specific
state provisioning. This document relies on the semantics of RSVP
that [P2MP RSVP-TE] inherits for building Hose LSPs or VPN Tunnels.
A VPN Tunnel comprises of one or more Hose LSPs. A VPN Tunnel is
identified by a VPN SESSION object. This object is a renaming of the
P2MP SESSION object in [P2MP RSVP-TE]. In the VPN-specific state
provisioning, all of the S2L sub-LSPs in a VPN Tunnel MUST share the
reserved resource for the VPN Tunnel.
A Hose LSP is identified by the combination of the VPN SESSION and
the VPN SENDER TEMPLATE object. In the hose-specific state
provisioning, all of the S2L sub-LSP in a Hose LSP MUST share the
reserved resource for the Hose LSP.
Path computation aspects for Hose LSP (a hose tree) and VPN Tunnel (a
VPN tree or graph) are outside of the scope of this document.
Specifically, the extensions explained in this draft include the RSVP
message formats and the structures of path state block (PSB) and
Byun Expires December 20, 2006 [Page 5]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
reservation state block (RSB). In addition, for the assignment of
labels and the label switching for transmission of unicast data, S2L
LABEL object is added in the S2L sub-LSP descriptor defined in the
[P2MP RSVP-TE]. In order to identify the multiple user sites
belonging to the same VPN and attached to a single ingress PE, Hose
ID field is defined and included in the VPN SENDER TAMPLATE and VPN
FILTER SPEC objects. The modifications to the processing of RSVP
messages, in order to compute the amount of resources to be reserved
on a link according to the hose-specific or VPN-specific state
provisioning, are described.
The extended resource reservation protocol enables resource
reservation dynamically and automatically according to hose-specific
or VPN specific state provisioning.
4. Path Message
4.1. Path Message Format
This section describes modifications made to the Path message format
specified in [P2MP RSVP-TE].
The VPN SESSION object is a renaming of the P2MP SESSION object in
[P2MP RSVP-TE]. It is composed of the VPN session ID, the VPN tunnel
ID and the extended VPN tunnel ID. For the VPN session ID, a
multicast group IP address, which needs to be distributed to the PE
routers serving a same VPN by the administrator, SHOULD be used. The
VPN SESSION object refers only to signaling state and not data plane
multicast.
The VPN SESSION object identifies a VPN Tunnel. For the VPN-specific
state provisioning, all of the S2L sub-LSP in a VPN Tunnel SHOULD
share the reserved resource for the VPN Tunnel.
VPN SENDER TEMPLATE object of Path message is extended with Hose ID
field, and as a result the VPN SENDER TEMPLATE object is composed of
the tunnel sender address, the Hose ID, and the LSP ID. The VPN
SENDER TEMPLATE object is defined in section 6.1.
Tunnel sender address, Hose ID, and LSP ID are included in the VPN
SENDER TEMPLATE object. Tunnel sender address specifies the ingress
PE by which the Path message is generated. For each hose attached to
the PE, unique Hose ID is assigned and a corresponding LSP is
established. For the purpose of modifying the route or the
reservation state of the Hose LSP for a certain hose, a new Hose LSP
can be established, and as a result multiple Hose LSPs may exist for
a single hose temporarily. In this case, the Path messages for those
Byun Expires December 20, 2006 [Page 6]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
Hose LSPs contain the same Hose ID. Therefore, an additional ID is
necessary to differentiate those Hose LSPs(the original and newly
established Hose LSPs), and LSP ID is deployed to this end. Hose LSPs
with the same Hose ID but with different LSP IDs share reserved
resources where they share hops.
<Path Message> ::=<Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...]
[ <MESSAGE_ID> ]
<VPN SESSION><RSVP HOP>
<TIME VALUES>
[ <EXPLICIT ROUTE> ]
<LABEL REQUEST>
[ <PROTECTION> ]
[ <LABEL SET>...]
[ <SESSION ATTRIBUTE> ]
[ <NOTIFY REQUEST> ]
[ <ADMIN STATUS> ]
[ <POLICY DATA> ]
<sender descriptor>
[ <S2L sub-LSP descriptor list> ]
Following is the format of the S2L sub-LSP descriptor list.
<S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor>
[ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor> ::= <S2L SUB LSP>
[ <VPN SECONDARY EXPLICIT ROUTE> ]
The VPN SECONDARY EXPLICIT ROUTE is a renaming of the P2MP SESSION
object in [P2MP RSVP-TE].
Path message processing is described in the section 4.3
4.2. Path State Block (PSB)
Each router maintains PSBs for the Path messages. For hose-specific
or VPN-specific state provisioning, each PSB holds path state for a
particular <VPN session, VPN sender,_Hose ID> pair, defined by VPN
SESSION and VPN SENDER_TEMPLATE objects, respectively, received in a
Path message. The PSB basically follows the [RFC2209] format. PSB
maintains the following values obtained from a PATH message:
- VPN SESSION
- VPN SENDER TEMPLATE
Byun Expires December 20, 2006 [Page 7]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
- SENDER TSPEC
- The remaining IP TTL
- The previous hop IP address and the Logical Interface Handle
(LIH) from a PHOP object
- POLICY_DATA and/or ADSPEC objects (optional)
- Incoming interface
- S2L sub-LSP descriptor list
- Non_RSVP flag
- E_Police flag
- Local_Only flag
Each S2L sub-LSP descriptor is assigned with an Outgoing interface
and an expiration time.
4.3. Path Message Processing
An ingress PE of a VPN sends a Path message to egress PEs belonging
to the same VPN in order to establish S2L sub-LSPs.
Since the semantics of objects for hose-specific or VPN-specific
state provisioning mechanism are different, new C-Types for each
object are assigned. We assume that the provisioning mechanism is
decided by VPN customer and the ingress PEs are informed about it
though VPN administrator.
Except for the things explicitly specified in this section the Path
message processing follows the same procedure defined in the [P2MP
RSVP-TE]. A Path message can signal a S2L sub-LSP or multiple S2L
sub-LSPs that may belong to the same Hose LSP. Also, the VPN
SECONDARY EXPLCIT ROUTE objects follow the same compression mechanism
as that of the P2MP SECONDARY EXPLCIT ROUTE objects of the [P2MP
RSVP-TE]. The detailed Path message processing is defined in section
5.2 of [P2MP RSVP-TE].
If a LSR node receives a Path message, it first searches for a PSB
whose [VPN session, VPN sender, Hose ID] pair matches the
corresponding objects in the Path message, and whose IncInterface
matches InIf. The IncInterface is the expected incoming interface and
the InIf is the interface where Path message arrives. If there is no
Byun Expires December 20, 2006 [Page 8]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
matching PSB, then a new PSB is created. Otherwise, if a matching PSB
exists, S2L sub-LSP descriptors specified in the Path message are
searched from the matching PSB. For the S2L sub-LSP descriptors that
are already registered in the matching PSB, the corresponding entries
from the matching PSB are updated and refreshed. For the S2L sub-LSP
descriptors that are hot registered in the matching PSB yet, a new
S2L sub-LSP descriptor entry is added in the matching PSB.
5. Resv Message
5.1. Resv Message Format
This section describes modifications made to the Resv message format
specified in [P2MP RSVP-TE].
<Resv Message>::= <Common Header>[<INTEGRITY>]
[[<MESSAGE_ID_ACK>|<MESSAGE_ID_NACK>]...]
[<MESSAGE_ID>]
<VPN SESSION><RSVP HOP>
<TIME VALUES>
[<RESV_CONFIRM>][<SCOPE>]
[<NOTIFY REQUEST>]
[<ADMIN STATUS>]
[<POLICY DATA>...]
<STYLE>
<flow descriptor list>
<flow descriptor list>::=<FF flow descriptor list>
|<SE flow descriptor>
For the hose-specific state provisioning,
<FF flow descriptor list>::=<FF flow descriptor>
|<FF flow descriptor list><FF flow descriptor>
<FF flow descriptor>::=[<HOSE FLOWSPEC>] <VPN FILTER SPEC> <LABEL>
[<RECORD ROUTE>] [<S2L sub-LSP descriptor list>]
<SE flow descriptor>::=<HOSE FLOWSPEC><SE filter spec list>
For the VPN-specific state provisioning,
<SE flow descriptor>::=<VPN FLOWSPEC><SE filter spec list>
For the hose-specific and VPN-specific state provisioning, the S2L
sub-LSP descriptor list and SE filter spec list are constructed as
follows,
Byun Expires December 20, 2006 [Page 9]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
<SE filter spec list>::=<SE filter spec>
|<SE filter spec list><SE filter spec>
<SE filter spec>::= <VPN FILTER SPEC> <LABEL> [<RECORD ROUTE>]
[<S2L sub-LSP descriptor list>]
<S2L sub-LSP descriptor list>::= <S2L sub-LSP descriptor>
[ <S2L sub-LSP descriptor list> ]
<S2L sub-LSP descriptor>::=<S2L SUB-LSP>
[<S2L LABEL>]
[<VPN SECONDARY RECORD ROUTE>]
Note that a Resv message can signal multiple S2L sub-LSPs that may
belong to the same VPN FILTER SPEC object or different VPN FILTER
SPEC objects. The proposed mechanism assigns the different labels for
each S2L sub-LSP, whereas the same label should be allocated if the
<tunnel sender address, LSP ID> fields of the FILTER SPEC object are
the same in the [P2MP RSVP-TE]. To this end, the S2L LABEL object is
defined in the S2L sub-LSP descriptor. The S2L LABEL object is the
same with the LABEL object in the [P2MP RSVP-TE]. The first S2L SUB-
LSP object's label is specified in the LABEL object. Labels of
subsequent S2L sub-LSPs are specified in the S2L LABLE objects. For
each S2L sub-LSP object, a separate S2L LABEL object exists. A S2L
LABLE object corresponds to the following S2L SUB-LSP object.
The S2L sub-LSP descriptor of a Resv message has the same format as
the S2L sub-LSP descriptor of a Path message defined in section 4.1
except for that a VPN SECONDARY RECORD ROUTE object is used in place
of a VPN SECONDARY EXPLITE ROUTE object. The VPN SECONDARY RECORD
ROUTE objects follow the same compression mechanism as the VPN
SECONDARY EXPLCIT ROUTE objects.
The HOSE FLOWSPEC in the FF flow descriptor and the VPN FLOWSPEC in
the SE flow descriptor is the renaming of the FLOWSPEC object in the
[P2MP RSVP-TE] respectively.
The processing of a Resv message is described in the section 5.4
5.2. Resv State Block (RSBs)
Each router maintains RSBs for the Resv messages. A RSB is maintained
for each hose(in hose-specific state provisioning) or VPN(in VPN-
specific state provisioning) at the arriving interface of a Resv
message. The RSB basically follows the [RFC2209] format except for
the things explicitly specified in this draft.
Byun Expires December 20, 2006 [Page 10]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
For the hose-specific state provisioning, RSB is created for each
hose. If the reservation style is FF then the RSB is created for each
[VPN SESSION, next hop IP address and VPN FILTER SPEC] tupple and if
the reservation style is SE then it is created for each [VPN SESSION,
next hop IP address and VPN FILTER SPEC list] tupple. In case of the
hose-specific state provisioning, RSB contains:
- VPN SESSION
- Next hop IP address
- The outgoing (logical) interface OI on which the reservation is
to be made or has been made(RESV interface)
- STYLE
- FF flow descriptor or SE flow descriptor
For the VPN-specific state provisioning, it is created for each [VPN
SESSION, next hop IP address and VPN FILTER SPEC list> i.e., per VPN
Tunnel. The RSB contains:
- VPN SESSION
- Next hop IP address
- The outgoing (logical) interface OI on which the reservation is
to be made or has been made(RESV interface)
- STYLE
- SE flow descriptor
Each FF flow descriptor or SE filter spec in a RSB includes a S2L
sub-LSP descriptor list. Each S2L sub-LSP descriptor SHOULD be
assigned with a label and expiration time, respectively.
5.3. Reservation Style
For the hose-specific state provisioning, the reservation style in
the Resv messages can either be FF or SE. Hose LSPs belonging to the
same VPN Tunnel can be signaled with the different reservation style.
Irrespective of whether the reservation style is FF or SE, the S2L
sub-LSPs that belong to the same Hose LSP MUST share resources where
they share hops, but MUST NOT share labels. If the reservation style
is FF, S2L sub-LSPs that belong to different Hose LSP MUST NOT share
resources. SE style is used for resources sharing between the old and
Byun Expires December 20, 2006 [Page 11]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
new Hose LSPs when a new Hose LSP is established to modify or replace
an existing Hose LSP.
To uniquely identify old Hose LSP and New Hose LSP as a Hose LSP, the
tunnel ingress node's IP address, which is placed in the extended
tunnel ID is used in the VPN SESSION object. If the reservation style
is SE, then the S2L sub-LSPs that belong to the different Hose LSP,
but with the same Hose ID of the VPN SENDER TEAMPLATE and the same
VPN SESSION SHOULD share resources where they share hops.
For the VPN-specific state provisioning, the reservation style in the
Resv messages MUST be SE. All of the S2L sub-LSPs that belong to the
same VPN Tunnel MUST signal with the SE style. The S2L sub-LSPs that
belong to the same VPN Tunnel SHOULD share resources where they share
hops, but MUST not share labels.
Our scheme differs from the [P2MP RSVP-TE] in the following aspects:
- In the [P2MP RSVP-TE], the S2L sub-LSPs that belong to the same
P2MP LSP MUST share resources, and they MUST share labels.
However, in our scheme, the S2L sub-LSPs that belong to the
same Hose LSP MUST share resources, but they MUST NOT share
labels.
- All of the P2MP LSPs that belong to the same P2MP Tunnel MUST
signal with the same reservation style. In our scheme, Hose
LSPs belonging to the same VPN Tunnel can be signaled with the
different reservation style.
- In the hose-specific state provisioning, SE style reservation
it is used for resources sharing between the old and new Hose
LSPs. For the VPN-specific state provisioning, it is used for
resources sharing among all of the Hose LSPs belonging to the
same VPN Tunnel.
5.4. Resv Message Processing
When an egress PE receives a Path message, corresponding Resv message
is generated and sent back to the source of the Path message. The
Resv message has to be set with the different STYLE object, which
specifies the reservation style, according to the provisioning
mechanisms. The egress PE decides the reservation style according to
the C-type specified on VPN SENDER TEMPLATE object.
In order to have the S2L LSPs of a Hose LSP share the resource, the
reservation style of the Resv message for hose-specific state
provisioning need to be set to FF. In this case, the FF flow
Byun Expires December 20, 2006 [Page 12]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
descriptor in the Resv message contains the S2L sub-LSP descriptor
list with one and more entries. The S2L sub-LSPs included in the S2L
sub-LSP descriptor list can share the resource.
One of the requirements for Traffic Engineering is the capability to
reroute an established TE tunnel under a number of conditions, based
on administrative policy. In order to have the reroute or bandwidth-
increase operation, SE style may be use for the hose-specific
provisioning. Since the semantics of VPN SENDER TEMPLATE and VPN
FILTER SPEC objects are changed, new C-Types are assigned.
In order to have all of the S2L sub-LSPs of a VPN share the resource,
the reservation style of the Resv message for VPN-specific state
provisioning need to be set to SE.
Note that intermediate router may integrate the multiple Resv
messages, and generate a single Resv message with multiple flow
descriptors in the flow descriptor list.
Figure 1 shows a merged FF flow descriptor in the FF flow descriptor
list for hose-specific state provisioning.
+------------------------------+
+ HOSE FLOW SPEC +
+------------------------------+
+ VPN FILTER SPEC +
+------------------------------+
+ Label +
+------------------------------+
+ RECORD ROUTE +
+------------------------------+
+ S2L sub-LSP descriptor 1 +
+ S2L sub-LSP descriptor 2 +
+ . . . +
+------------------------------+
Figure 1 A merged FF flow descriptor for a Hose LSP
The FF Flow descriptor is generated for each VPN FILTER SPEC. If the
received Resv messages have the same VPN SESSION and VPN FILTER SPEC
objects, they are for the same Hose LSP. Therefore, they are merged
into a single FF flow descriptor which includes every S2L sub-LSP
descriptors from the merged Resv messages.
In the VPN-specific state provisioning, an intermediate LSP may
combine flow descriptors with different VPN FILTER SPEC objects if
they have the same VPN SESSION object. Figure 2 shows a merged SE
Byun Expires December 20, 2006 [Page 13]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
flow descriptor in the SE filter spec list for VPN-specific state
provisioning.
+------------------------------+
+ VPN FLOW SPEC +
+------------------------------+
+ VPN FILTER SPEC: S1 +
+------------------------------+
+ LABLE +
+------------------------------+
+ RECORD ROUTE +
+------------------------------+
+ S2L sub-LSP descriptor 1 +
+ S2L sub-LSP descriptor 2 +
+ . . . +
+------------------------------+
+ VPN FILTER SPEC: S2 +
+------------------------------+
+ LABEL +
+------------------------------+
+ RECORD ROUTE +
+------------------------------+
+ S2L sub-LSP descriptor 1 +
+ S2L sub-LSP descriptor 2 +
+ . . . +
+------------------------------+
Figure 2 A merged SE flow descriptor for a VPN Tunnel
The LSR MUST assign a separate label for each S2L sub-LSP. The label
in LABEL object is for the first S2L SUB-LSP object. Labels of
subsequent S2L sub-LSP in S2l sub-LSP descriptor list is specified by
the corresponding S2L LABLE object in the S2L sub-LSP descriptor.
If an LSR receives a Resv message, it first validates the legitimacy
of the received Resv message by checking whether there is a
corresponding PSB. The corresponding PSB of a Resv message is defined
as the PSB with [VPN SESSION, VPN SENDER TEMPLATE, S2L sub-LSP
descriptor, OutIf] that matches [VPN SESSION, VPN FILTER SPEC, S2L
sub-LSP descriptor, OI(RESV interface)] of the received Resv message.
If there is no existing PSB for VPN SESSION and if a PSB is found
with a matching VPN SENDER TEAPLATE then send an error messages. If a
matching PSB exists, the active RSB is then looked for. An RSB is
maintained for each VPN at the arriving interface of a Resv message.
The active RSB is the RSB maintained at the Resv message arriving
interface with the [VPN SESSION] of the Resv message.. If the active
RSB exists, it is updated and refreshed with the information in the
Resv message. Otherwise, a new RSB is created for the Resv messge.
Byun Expires December 20, 2006 [Page 14]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
For the hose-specific state provisioning, let B_Hose be the bandwidth
value of Hose FLOWSPEC object, B_VPN be the bandwidth value of VPN
FLOWSPEC object, P_corrPSB be the bandwidth value of Sender Tspec
object in the matching PSB, S be the set of user sites attached to
the PE, H_s be the size of hose from the PE to the user site s, and
M_Hose be the bandwidth value of Hose FLOWSPEC object in the received
Resv message. Specifically, the B_Hose and the B_VPN in the active
RSB are set as follows respectively:
o If the router is an egress PE, then
o B_Hose = min(P_corrPSB, sum_{s IN S}H_s)
o Otherwise, B_Hose = M_Hose
For the VPN-specific state provisioning, let K be the set of PSBs
with (VPN SESSION, InIf) of the mating PSB, P_k be the bandwidth
value of Sender Tspec in the PSB k, and M_VPN be the bandwidth value
of VPN FLOWSPEC object in the received Resv message.
o If the router is an egress PE, then
o B_VPN = min(sum_{k IN K}P_k, sum_{s IN S}H_s)
o Otherwise, B_VPN = M_VPN
After the update or creation of a RSB, the Resv message is
transmitted to the next hop toward the traffic source. According to
provisioning mechanisms, the bandwidth values of VPN FLOWSPEC or Hose
FLOWSPEC objects, denoted by M_VPN and M_Hose respectively, in the
Resv message to be transmitted, are computed. Let H be the set of
RSBs with (VPN SESSION, VPN FILTER SPEC, NHOP) of active RSB,
B_h_Hose be the bandwidth value of Hose FLOWSPEC object in RSB h, V
be the set of RSBs with (VPN SESSION, NHOP) of active RSB, and
B_v_VPN be the bandwidth value of VPN FLOWSPEC object in RSB v. Then
M_Hose and M_VPN is computed as follows:
o M_Hose = min (P_corrPSB, sum_{h in H}B_h_Hose)
o M_VPN = min (sum_{k IN K}P_k, sum_{v IN V}B_v_VPN)
6. New and Updated Message objects
This section presents the RSVP object formats modified by this
document.
Byun Expires December 20, 2006 [Page 15]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
6.1. VPN SENDER TEMPLATE object
In the VPN-specific state provisioning, all of the Hose LSPs
belonging to the VPN tunnel share the reserved resources where they
share hops. Whereas, in the hose-specific state provisioning, S2L
sub-LSPs belonging to the Hose LSPs with the same Hose ID share the
reserved resources where they share hops.
In both of the provisioning mechanisms, each of the S2L sub-LSPs
comprising the VPN tunnel or the Hose LSPs should use independent
labeling and switching to one another.
6.1.1. VPN IPv4 VPN SENDER TEMPLATE object
Class = SENDER TEMPLATE, VPN SENDER TEMPLATE_IPv4 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hose ID | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Group Originator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel sender address
See [RFC3209]
Hose ID
A 16-bit identifier used in the VPN SENDER_TEMPLATE and the VPN
FILTER SPEC.
Sub-Group Originator ID
See [P2MP-RSVP TE]
Sub-Group ID
See [P2MP-RSVP TE]
LSP ID
Byun Expires December 20, 2006 [Page 16]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
See [RFC3209]
6.1.2. VPN IPv6 VPN SENDER TEMPLATE object
Class = SENDER TEMPLATE, VPN SENDER TEMPLATE_IPv6 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hose ID | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Group Originator ID |
| (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel sender address
See [RFC3209]
Hose ID
A 16-bit identifier used in the VPN SENDER_TEMPLATE and the VPN
FILTER SPEC.
Sub-Group Originator ID
See [P2MP-RSVP TE]
Sub-Group ID
See [P2MP-RSVP TE]
LSP ID
See [RFC3209]
6.2. VPN FILTER SPEC object
The FILTER SPEC object is canonical to the VPN SENDER TEMPLATE object.
Byun Expires December 20, 2006 [Page 17]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
6.2.1. VPN IPv4 FILTER SPEC object
Class = FILTER SPEC, VPN IPv4 C-Type = TBD
The format of the VPN IPv4 FILTER SPEC object is identical to the VPN
IPv4 SENDER TEMPLATE object.
6.2.2. VPN IPv6 FILTER SPEC object
Class = FILTER SPEC, VPN IPv6 C-Type = TBD
The format of the VPN IPv6 FILTER SPEC object is identical to the VPN
IPv6 SENDER TEMPLATE object.
6.3. SUB_LABEL object
The format of the SUB_LABEL object is identical to the LABEL object
in the [RSVP-TE] and the [P2MP RSVP-TE].
7. Security Considerations
This document does not introduce any new security issues. The
security issues identified in [RFC3209] and [RFC3473] are still
relevant.
8. IANA Considerations
8.1. New Class Numbers
IANA is requested to assign the following Class Numbers for the new
object classes introduced. The Class Types for each of them are to be
assigned via standards action. The sub-object types for the VPN
SESONDARY_EXPLICIT_ROUTE, VPN_SECONDARY_RECORD_ROUTE, S2L sub-LABEL,
VPN FILTER SPEC, VPN FLOWSPEC, Hose FLOWSPEC follow the same IANA
considerations as those of the SESSION, ERO, RRO, FILTER SPEC,
FLOWSPEC [RFC3209].
The sub-object types for the VPN SESSION, S2L_SUB_LSP follow the same
IANA considerations as those of the P2MP SESSION, S2L_SUB_LSP [P2MP
RSVP-TE].
8.2. New Class Types
Class Name = VPN_SENDER_TEAMPLATE
C-Type
Byun Expires December 20, 2006 [Page 18]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
VPN_SENDER_TEMPLATE_IPv4 C-Type
VPN_SENDER_TEMPLATE_IPv6 C-Type
Class Name = VPN_FILTER_SPEC
C-Type
VPN_FILTER_SPEC_IPv4 C-Type
VPN_FILTER_SPEC IPv6 C-Type
Class Name = S2L_SUB_LABEL
C-Type
S2L_SUB_LABEL C-Type
9. Acknowledgments
This research was supported by the MIC(Ministry of Information and
Communication), Korea, under the ITRC(Information Technology Research
Center) support program supervised by the IITA(Institute of
Information Technology Assessment, and by the ITEP(Korea Institute of
Industrial Technology Evolution and Planning).
Byun Expires December 20, 2006 [Page 19]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
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.
[RFC4031] M. Carugi, Ed., D. McDysan, Ed., "Service Requirements for
Layer 3 Provider Provisioned Virtual Private Networks
(PPVPNs)", RFC4031, April 2005
[RFC4461] S. Yasukawa, Ed., "Signaling Requirements for Point-to-
Multipoint Traffic Engineered MPLS LSPs", RFC4461, April
2006
[P2MP RSVP-TE] R.Aggarwal, D. Paradimitriou, S. Yasukawa, "Extensions
to RSVP-TE for Point to Multipoint TE LSPs", draft-
ietf-mpls-rsvp-te-p2mp-05.txt, May 2006, work in
progress
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC3209, December 2001
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1,
Functional Specification", RFC 2205, September 1997
[RFC4110] R. Callon, M. Suzuki, "A Framework for Layer 3 Provider-
Provisioned Virtual Private Networks (PPVPNs)", RFC4110,
July 2005
10.2. Informative References
[Duf2002] N.G. Duffield, P. Goyal, A. Greenberg, P. Mishra, K.K.
Ramakrishnan, J. E. Van der Merwe, "Resource Management
With Hoses: Point-to-Cloud Services for Virtual Private
Networks", IEEE/ACM Transactions on Networking, Vol.10,
No.5, October 2002
Byun Expires December 20, 2006 [Page 20]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
Author's Addresses
Haesun Byun
Ewha Woman's University
11-1 Daehyun-Dong, Seodaemun-Gu, Seoul
Phone: 82-2-3277-3507
Email: ladybhs@ewhain.net
Meejeong Lee
Ewha Woman's University
11-1 Daehyun-Dong, Seodaemun-Gu, Seoul
Phone: 82-2-3277-2388
Email: lmj@ewha.ac.kr
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
Byun Expires December 20, 2006 [Page 21]
Internet-Draft draft-byun-vpn-provision-rsvp-te-00.txt June 2006
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Byun Expires December 20, 2006 [Page 22]