MPLS Working Group F. Zhang, Ed.
Internet-Draft ZTE
Intended status: Standards Track R. Jing
Expires: December 3, 2011 China Telecom
June 01, 2011
RSVP-TE Extensions to Establish Associated Bidirectional LSP
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-01
Abstract
The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654],
describes that MPLS-TP MUST support associated bidirectional point-
to-point LSPs.
This document provides a method to bind two unidirectional Label
Switched Paths (LSPs) into an associated bidirectional LSP. The
association is achieved by using a new Association Type in the
Extended ASSOCIATION object.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 3, 2011.
Copyright Notice
Copyright (c) 2011 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
(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
Zhang & Jing Expires December 3, 2011 [Page 1]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Association of Two Reverse Unidirectional LSPs . . . . . . . . 4
3.1. Provisioning Model . . . . . . . . . . . . . . . . . . . . 4
3.2. Signaling Procedure . . . . . . . . . . . . . . . . . . . 4
3.2.1. Single Sided Provisioning Model . . . . . . . . . . . 5
3.2.2. Double Sided Provisioning Model . . . . . . . . . . . 6
3.2.3. Asymmetric Bandwidth LSPs . . . . . . . . . . . . . . 8
3.2.3.1. Error Handling . . . . . . . . . . . . . . . . . . 9
3.3. Recovery Considerations . . . . . . . . . . . . . . . . . 10
4. Extensions to the Extended ASSOCIATION object . . . . . . . . 10
5. REVERSE_TSPEC Object . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.1. Association Type . . . . . . . . . . . . . . . . . . . . . 13
6.2. REVERSE_TSPEC Object . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative references . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Zhang & Jing Expires December 3, 2011 [Page 2]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
1. Introduction
The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654]
describes that MPLS-TP MUST support associated bidirectional point-
to-point LSPs. Furthermore, an associated bidirectional LSP is
useful for protection switching, for Operations, Administrations and
Maintenance (OAM) messages that require a reply path.
The requirements described in [RFC5654] are specifically mentioned in
Section 2.1. (General Requirements), and are repeated below:
7. MPLS-TP MUST support associated bidirectional point-to-point
LSPs.
11. The end points of an associated bidirectional LSP MUST be aware
of the pairing relationship of the forward and reverse LSPs used to
support the bidirectional service.
12. Nodes on the LSP of an associated bidirectional LSP where both
the forward and backward directions transit the same node in the same
(sub)layer as the LSP SHOULD be aware of the pairing relationship of
the forward and the backward directions of the LSP.
14. MPLS-TP MUST support bidirectional LSPs with asymmetric
bandwidth requirements, i.e., the amount of reserved bandwidth
differs between the forward and backward directions.
50. The MPLS-TP control plane MUST support establishing associated
bidirectional P2P LSP including configuration of protection functions
and any associated maintenance functions.
The above requirements are also repeated in
[I-D.ietf-ccamp-mpls-tp-cp-framework].
The notion of association, as well as the corresponding Resource
reSerVation Protocol (RSVP) ASSOCIATION object, is defined in
[RFC4872], [RFC4873] and [I-D.ietf-ccamp-assoc-info] . In that
context, the object is used to associate recovery LSPs with the LSP
they are protecting. This object also has broader applicability as a
mechanism to associate RSVP state, and [I-D.ietf-ccamp-assoc-ext]
defines the Extended ASSOCIATION object that can be more generally
applied.
This document provides a method to bind two unidirectional Label
Switched Paths (LSPs) into an associated bidirectional LSP. The
association is achieved by using a new Association Type in the
Extended ASSOCIATION object.
Zhang & Jing Expires December 3, 2011 [Page 3]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
2. 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].
3. Association of Two Reverse Unidirectional LSPs
3.1. Provisioning Model
The associated bidirectional LSP's forward and backward directions
are set up, monitored, and protected independently as required by
[RFC5654]. Configuration information regarding the LSPs can be sent
to one end or both ends of the LSP. Depending on the method chosen,
there are two models of signaling associated bidirectional LSP. The
first model is the single sided provisioning, the second model is the
double sided provisioning.
For the single sided provisioning, the configurations are sent to one
end. Firstly, a unidirectional tunnel is configured on this end,
then a LSP under this tunnel is initiated with the Extended
ASSOCIATION object carried in the Path message to trigger the peer
end to set up the corresponding reverse TE tunnel and LSP.
For the double sided provisioning, the two unidirectional TE tunnels
are configured independently, then the LSPs under the tunnels are
signaled with the Extended ASSOCIATION objects carried in the Path
message to indicate each other to associate the two LSPs together to
be an associated bidirectional LSP.
A number of scenarios exist for binding LSPs together to be an
associated bidirectional LSP. These include: (1) both of them do not
exist; (2) both of them exist; (3) one LSP exists, but the other one
need to be established. In all scenarios described, the provisioning
models discussed above are applicable.
3.2. Signaling Procedure
This section describes the signaling procedures for associating
bidirectional LSPs.
Consider the topology described in Figure 1. (An example of
associated bidirectional LSP). The LSP1 [via nodes A,D,B] (from west
to east) and LSP2 [via nodes B,D,C,A] (from east to west) are being
established or have been established. These LSPs can be bound
together to form an associated bidirectional LSP.
Zhang & Jing Expires December 3, 2011 [Page 4]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
LSP1 is uniquely identified [I-D.ietf-mpls-tp-identifiers] by: West-
Global_ID::West-Node_ID::West-Tunnel_Num::West-LSP_Num.
LSP2 is uniquely identified [I-D.ietf-mpls-tp-identifiers] by: East-
Global_ID::East-Node_ID::East-Tunnel_Num::East-LSP_Num.
A-------D-------B
\ /
\ /
\ /
C
Figure 1: An example of associated bidirectional LSP
3.2.1. Single Sided Provisioning Model
For the single sided provisioning model, LSP1 is triggered by LSP2 or
LSP2 is triggered by LSP1. When LSP2 is triggered by LSP1, according
to the scenarios described above, the following cases may occur:
1. Both LSPs do not exist.
LSP1 is initialized at node A with the Extended ASSOCIATION object
inserted in the Path message, Association Type is set to
"Association of two reverse unidirectional LSPs", Association ID
set to West-LSP_Num, Association Source set to West-Node_ID,
Global Association Source set to West-Global_ID, and Extended
Association ID set to West-Tunnel_Num. Terminating node B is
triggered to set up LSP2 by the received Extended ASSOCIATION
object with the Association Type set to the value "Association of
two reverse unidirectional LSPs", the Association Object inserted
in LSP2's Path message is the same as in LSP1's Path message.
2. LSP1 exists, LSP2 needs to be established.
LSP1 is refreshed with the Extended ASSOCIATION object inserted in
the Path message, Association Type is set to "Association of two
reverse unidirectional LSPs", Association ID set to West-LSP_Num,
Association Source set to West-Node_ID, Global Association Source
set to West-Global_ID, and Extended Association ID set to West-
Tunnel_Num. Terminating node B is triggered to set up LSP2 by the
received Extended ASSOCIATION object with the Association Type set
to the value "Association of two reverse unidirectional LSPs", the
Association Object inserted in LSP2's Path message is the same as
in LSP1's Path message.
Zhang & Jing Expires December 3, 2011 [Page 5]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
3. LSP1 does not exist, LSP2 has been established.
LSP1 is initialized with the Extended ASSOCIATION object inserted
in the Path message, Association Type is set to "Association of
two reverse unidirectional LSPs", Association ID set to East-
LSP_Num, Association Source set to East-Node_ID, Global
Association Source set to East-Global_ID, and Extended Association
ID set to East-Tunnel_Num. Terminating node B is triggered to
refresh LSP2's Path message, with the received Extended
ASSOCIATION object inserted.
4. Both LSP1 and LSP2 exist.
LSP1 is refreshed with the Extended ASSOCIATION object inserted in
the Path message, Association Type is set to "Association of two
reverse unidirectional LSPs", Association ID set to East-LSP_Num,
Association Source set to East-Node_ID, Global Association Source
set to East-Global_ID, and Extended Association ID set to East-
Tunnel_Num. Terminating node B is triggered to refresh LSP2's Path
message, with the received Extended ASSOCIATION object inserted.
When LSP1 is triggered by LSP2, the same rules are applicable. Based
on the same values of the Association objects in the two LSPs' Path
message, the two LSPs can be bound together to be an associated
bidirectional LSP.
3.2.2. Double Sided Provisioning Model
For the double sided provisioning model, Similarly, according to the
scenarios described above, the following cases may occur:
1. LSP1 and LSP2 do not exist.
LSP1 and LSP2 are concurrently initialized with the Extended
ASSOCIATION object inserted in the their Path messages, For LSP1,
Association Type is set to "Association of two reverse
unidirectional LSPs", Association ID set to West-LSP_Num,
Association Source set to West-Node_ID, Global Association Source
set to West-Global_ID, and Extended Association ID set to West-
Tunnel_Num. For LSP2, Association Type is set to "Association of
two reverse unidirectional LSPs", Association ID is set to East-
LSP_Num, Association Source set to East-Node_ID, Global
Association Source set to East-Global_ID, and Extended Association
ID set to East-Tunnel_Num. According to the general rules defined
in [I-D.ietf-ccamp-assoc-ext], the two LSPs cannot be bound
together to be an associated bidirectional LSP because of the
different values. In this case, the two edge nodes firstly MUST
compare their Global-Node_ID, then the bigger one sends Path
refresh message, replacing the old Extended ASSOCIATION object
with the new Extended ASSOCIATION object carried in the reverse
LSP. Based on this Path refresh message, the two LSPs can be
Zhang & Jing Expires December 3, 2011 [Page 6]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
bounded together to be an associated bidirectional LSP also.
2. LSP1 exists, LSP2 needs to be established.
For LSP1, Association Type is set to "Association of two reverse
unidirectional LSPs", Association ID set to West-LSP_Num,
Association Source set to West-Node_ID, Global Association Source
set to West-Global_ID, and Extended Association ID set to West-
Tunnel_Num. For LSP2, Node B has known the existence of LSP1, so
the Association Type is set to "Association of two reverse
unidirectional LSPs", Association ID set to West-LSP_Num,
Association Source set to West-Node_ID, Global Association Source
set to West-Global_ID, and Extended Association ID set to West-
Tunnel_Num.
3.LSP1 does not exist, LSP2 has been established.
For LSP1, Node A has known the existenc of LSP2. So the
Association Type is set to "Association of two reverse
unidirectional LSPs", Association ID set to East-LSP_Num,
Association Source set to East-Node_ID, Global Association Source
set to East-Global_ID, and Extended Association ID set to East-
Tunnel_Num. For LSP2, Node B does not know the existence of LSP1,
so Association Type is set to "Association of two reverse
unidirectional LSPs", Association ID set to East-LSP_Num,
Association Source set to East-Node_ID, Global Association Source
set to East-Global_ID, and Extended Association ID set to East-
Tunnel_Num.
4. Both LSP1 and LSP2 exist.
In this case, Both node A and Node B know the existence of the
reverse LSPs. The two edge nodes firstly MUST compare their
Global-Node_ID, then the bigger one sends Path refresh message,
with the reverse LSP's identifier inserted in the Extended
ASSOCIATION object, and the smaller one sends Path refresh
message, with its own LSP's identifier inserted in the Extended
ASSOCIATION object. For example, assuming that the node A has the
bigger Global-Node_ID. For LSP1, the Association Type is set to
"Association of two reverse unidirectional LSPs", Association ID
set to East-LSP_Num, Association Source set to East-Node_ID,
Global Association Source set to East-Global_ID, and Extended
Association ID set to East-Tunnel_Num. For LSP2, the Association
Type is set to "Association of two reverse unidirectional LSPs",
Association ID set to West-LSP_Num, Association Source set to
East-Node_ID, Global Association Source set to East-Global_ID, and
Extended Association ID set to East-Tunnel_Num.
Based on the same values of the Association objects in the two LSPs'
Path message, the two LSPs can be bound together to be an associated
bidirectional LSP.
Zhang & Jing Expires December 3, 2011 [Page 7]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
3.2.3. Asymmetric Bandwidth LSPs
A variety of applications, such as internet services and the return
paths of OAM messages, exist and which MAY have different bandwidth
requirements for each direction. Additional [RFC5654] also specifies
an asymmetric bandwidth requirement. This requirement is
specifically mentioned in Section 2.1. (General Requirements), and
is repeated below:
14. MPLS-TP MUST support bidirectional LSPs with asymmetric
bandwidth requirements, i.e., the amount of reserved bandwidth
differs between the forward and backward directions.
The approach for supporting asymmetric bandwidth co-routed
bidirectional LSPs is defined in
[I-D.ietf-ccamp-asymm-bw-bidir-lsps-bis], which introduces three new
objects named UPSTREAM_FLOWSPEC object, UPSTREAM_TSPEC object and
UPSTREAM_ADSPEC object to represent the asymmetric upstream traffic
flow. For the asymmetric bandwidth associated bidirectional LSPs,
the existing SENDER_TSPEC, ADSPEC, and FLOWSPEC are complemented with
the addition of a new REVERSE_TSPEC object, which is used exactly in
the same fashion as the old SENDER_TSPEC object.
Consider the topology descirbed in Figure 1 in the context of
asymmetric associated bidirectional LSP, the following cases may
occur:
1. LSP1 and LSP2 do not exist.
For the single sided provisioning, taking LSP2 triggered by LSP1
as an example. The REVERSE_TSPEC object MUST be carried in the
LSP1's Path message together with the Extended ASSOCIATION object
whose Association Type is "Association of two reverse
unidirectional LSPs". The terminating node B is triggered to set
up the reverse LSP2 with the corresponding asymmetric bandwidth,
and the REVERSE_TSPEC object is converted to the SENDER_TSPEC
object in the Path message.
For the double sided provisioning, the REVERSE_TSPEC object MUST
be carried in the two LSPs' Path message together with the
Extended ASSOCIATION object whose Association Type is "Association
of two reverse unidirectional LSPs". Then the two terminating
ends MUST compare the values of the SENDER_TSPEC and REVERSE_TSPEC
objects in the two Path messages. If the values match, the end
with the bigger Global-Node_ID sends Path refresh message,
carrying the Extended ASSOCIATION object of the reverse LSP.
2. LSP1 exists, LSP2 needs to be established.
Zhang & Jing Expires December 3, 2011 [Page 8]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
For the single sided provisioning, taking LSP2 triggered by LSP1
as an example. The REVERSE_TSPEC object MUST be carried in the
LSP1's Path refresh message together with the Extended ASSOCIATION
object whose Association Type is "Association of two reverse
unidirectional LSPs". The terminating node B is triggered to set
up the reverse LSP2 with the corresponding asymmetric bandwidth,
and the REVERSE_TSPEC object is converted to the SENDER_TSPEC
object in the Path message.
For the double sided provisioning, the REVERSE_TSPEC object MUST
be carried in the LSP1's Path refresh message with the Extended
ASSOCIATION object whose Association Type is "Association of two
reverse unidirectional LSPs". There is no need to put the
REVERSE_TSPEC object in LSP2's Path message, for the Extended
ASSOCIATION object has indicated that LSP2 needs to be bound with
LSP1.
3. LSP1 does not exist, LSP2 has been established.
For the single sided provisioning, taking LSP2 triggered by LSP1
as an example. There is no need to put the REVERSE_TSPEC object
in LSP1's Path message, for the Extended ASSOCIATION object has
indicates that LSP1 needs to be bound with LSP2.
For the double sided provisioning, just the same reason, the
REVERSE_TSPEC object only needs to be carried in the LSP2's Path
refresh message.
4. Both LSP1 and LSP2 exist.
For the single sided provisioning, taking LSP2 triggered by LSP1
as an example. There is no need to put the REVERSE_TSPEC object
in LSP1's Path message also for the Extended ASSOCIATION object
has indicates that LSP1 needs to be bound with LSP2.
As to the double sided provisioning, just the same reason, the
REVERSE_TSPEC object does not need to be carried in the two LSPs'
Path messages.
Based on the same values of the Association objects in the two LSPs'
Path message, and the match of the REVERSE_TSPEC and SENDER_TSPEC
objects in the two LSPs' Path message (if the REVERSE_TSPEC object
exists), the two LSPs can be bound together to be an associated
bidirectional LSP.
3.2.3.1. Error Handling
Nodes not supporting the new class number of the REVERSE_TSPEC object
SHOULD respond with an "Unknown Object Class".
Zhang & Jing Expires December 3, 2011 [Page 9]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
3.3. Recovery Considerations
Consider the topology described in Figure 1, LSP1 and LSP2 form the
associated bidirectional LSP. Under the scenario of recovery, a
third LSP (LSP3) MAY be used to protect LSP1. LSP3 can be
established before or after the failure occurs, it can share the same
TE tunnel with LSP1 or not.
In the case that LSP3 is established after the failure occurs, the
Extended ASSOCIATION object with LSP2's identifier SHOULD be inserted
in LSP3's Path message since LSP2 has already existed. If LSP1 and
LSP2 are associated together by the LSP1's identifier, LSP2's Path
message is refreshed, an additional Extended ASSOCIAION object with
LSP2's identifier are inserted. If LSP1 and LSP2 are bound together
by the LSP2's identifier, there is no need to insert an additional
Extended ASSOCIATION object in LSP2's Path message.
In the case that LSP3 is established before the failure occurs. For
single sided provisioning, LSP3 is refreshed with the Extended
ASSOCIATION object, its values are filled by LSP2's identifier. Then
LSP2 is refreshed with this Extended ASSOCIATION object or not, see
the description in the above paragraph. For double sided
provisioning, if node A has the bigger Global-Node_ID than node B,
LSP3 is refreshed with the Extended ASSOCIATION object whose values
are filled by LSP2's identifier, and LSP2 is refreshed with this
Extended ASSOCIATION object or not, see the description in the above
paragraph. If node A has the smaller Global-Node_ID than node B,
LSP3 is refreshed with the Extended ASSOCIATION object whose values
are filled by LSP3's identifier, and LSP2 is refreshed with this
Extended ASSOCIATION object.
4. Extensions to the Extended ASSOCIATION object
The Extended ASSOCIATION object is defined in
[I-D.ietf-ccamp-assoc-ext], which enables MPLS-TP required
identification.
The Extended IPv4 ASSOCIATION object (Class-Num of the form 11bbbbbb
with value = 199, C-Type = TBA) has the format:
Zhang & Jing Expires December 3, 2011 [Page 10]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
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 | Class-Num(199)| C-Type (TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: Extended Association ID :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extended IPv4 ASSOCIATION object
The Extended IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb
with value = 199, C-Type = TBA) has the format:
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 | Class-Num(199)| C-Type (TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: Extended Association ID :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extended IPv6 ASSOCIATION object
o Association Type:
Zhang & Jing Expires December 3, 2011 [Page 11]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
In order to bind two reverse unidirectional LSPs to be an
associated bidirectional LSP, this document defines a new
Association Type:
Value Type
----- -----
4 (TBD) Association of two reverse unidirectional LSPs (A)
If the downstream nodes are not aware of the Association Type,
they MUST return a PathErr message with error code/sub-code "LSP
Admission Failure/Bad Association Type".
Under the context of this Association Type, any node associating
an associated bidirectional LSP MUST insert an ASSOCIATION object
with the following setting:
o Association ID:
The Association ID MUST be set to its own signaled LSP ID
(default); if known, it MAY be set to the LSP ID of the associated
reverse LSP.
o Association Source:
The Association source MUST be set to the tunnel sender address of
this LSP (default); if known, it May be set to the tunnel sender
address of the peer node.
o Global Association Source:
The format is described in [I-D.ietf-ccamp-assoc-ext].
o Extended Association ID:
Because the two LSPs (one is from west to east, and the other is
from east to west) are in different tunnels, the Association ID is
insufficient to uniquely identify association for associated
bidirectional LSP. Hence, this document adds specific rules: the
first 16-bits MUST be set to its own tunnel ID (default); if
known, it May be set to the tunnel ID of the the associated
reverse tunnel.
As described in [I-D.ietf-ccamp-assoc-ext], association is always
done based on matching Path state or Resv state. Upstream
initializted association is represented in Extended ASSOCIATION
objects carried in Path message and downstream initializted
Zhang & Jing Expires December 3, 2011 [Page 12]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
association is represented in Extended ASSOCIATION objects carried in
Resv messages. The new defined association type in this document is
only defined for use in upstream initialized association. Thus it
can only appear in Extended ASSOCIATION objects signaled in Path
message.
The rules associated with the processing of the Extended ASSOCIATION
objects in RSVP message are discussed in [I-D.ietf-ccamp-assoc-ext].
It said that in the absence of Association Type-specific rules for
identifying association, the included Extended ASSOCIATION objects
MUST be identical. This document adds no specific rules, the
association will always operate based on the same Extended
ASSOCIATION objects.
5. REVERSE_TSPEC Object
The REVERSE_TSPEC object is used in Path, PathTear, PathErr, and
Notify message (via sender descriptor). This includes the definition
of class type and format. It's class number is TBD (of the form
0bbbbbbb), and class type and format is the same as the SENDER_TSPEC
object.
This object modifies the RSVP message-related formats defined in
[RFC2205], [RFC3209] and [RFC3473]. See [RFC5511] for the syntax
used by RSVP. The format of the sender description for asymmetric
associated bidirectional LSPs is:
<sender descriptor>::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[<ADSPEC>]
[<RCEORD_ROUTE>]
[<SUGGESTED_LABEL>]
[<RECOVERY_LABEL>]
<REVERSE_TSPEC>
6. IANA Considerations
IANA is requested to administer assignment of new values for
namespace defined in this document and summarized in this section.
6.1. Association Type
Within the current document, a new Association Type is defined in the
Extended ASSOCIATION object.
Zhang & Jing Expires December 3, 2011 [Page 13]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
Value Type
----- -----
4 (TBD) Association of two reverse unidirectional LSPs (A)
6.2. REVERSE_TSPEC Object
A new class named REVERSE_TSPEC has been created in the 0bbbbbbb rang
(123,TBD) with the following definition:
Class Types or C-types:
Same values as SENDER_TPSCE object (C-Num 12)
There are no other IANA considerations introduced by this document.
7. Security Considerations
This document introduces a new association type, and except this,
there are no security issues about the Extended ASSOCIATION object
are introduced here.
Furthermore, this document introduces the REVERSE_TSPEC object for
use in GMPLS signaling [RFC3473], which is parallel the existing
SENDER_TSPEC object. As such, any vulnerabilities that are due to
the use of the old SENDER_TSPEC object now apply here also.
Otherwise, this document introduces no additional security
considerations. For a general discussion on MPLS and GMPLS related
security issues, see the MPLS/GMPLS security framework [RFC5920].
8. Acknowledgement
The authors would like to thank Lou Berger for his great guidance in
this work, George Swallow and Jie Dong for the discussion of
recovery, Lamberto Sterling for his valuable comments on the section
of asymmetric bandwidths, Daniel King for the review of the document,
Attila Takacs for the discussion of the provisioning model. At the
same time, the authors would also like to acknowledge the
contributions of Bo Wu, Xihua Fu, Lizhong Jin, and Wenjuan He for the
initial discussions.
9. References
Zhang & Jing Expires December 3, 2011 [Page 14]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
9.1. Normative references
[I-D.ietf-ccamp-assoc-ext]
Berger, L., Faucheur, F., and A. Narayanan, "RSVP
Association Object Extensions",
draft-ietf-ccamp-assoc-ext-00 (work in progress),
May 2011.
[I-D.ietf-mpls-tp-identifiers]
Bocci, M., Swallow, G., and E. Gray, "MPLS-TP
Identifiers", draft-ietf-mpls-tp-identifiers-04 (work in
progress), March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
9.2. Informative References
[I-D.ietf-ccamp-assoc-info]
Berger, L., "Usage of The RSVP Association Object",
draft-ietf-ccamp-assoc-info-02 (work in progress),
May 2011.
[I-D.ietf-ccamp-asymm-bw-bidir-lsps-bis]
Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)",
draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 (work in
progress), January 2011.
[I-D.ietf-ccamp-mpls-tp-cp-framework]
Andersson, L., Berger, L., Fang, L., Bitar, N., Gray, E.,
Takacs, A., Vigoureux, M., and E. Bellagamba, "MPLS-TP
Control Plane Framework",
draft-ietf-ccamp-mpls-tp-cp-framework-06 (work in
progress), February 2011.
Zhang & Jing Expires December 3, 2011 [Page 15]
Internet-Draft RSVP-TE Extensions of Associated LSP June 2011
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 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.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Authors' Addresses
Fei Zhang (editor)
ZTE
Email: zhang.fei3@zte.com.cn
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
Fan Yang
ZTE
Email: yang.fan5@zte.com.cn
Weilian Jiang
ZTE
Email: jiang.weilian@zte.com.cn
Zhang & Jing Expires December 3, 2011 [Page 16]
