Internet DRAFT - draft-cheng-gmpls-dynamic-trunking
draft-cheng-gmpls-dynamic-trunking
CCAMP Working Group Dean Cheng (Polaris Networks)
Internet Draft
Expiration Date: December 2001 June 2001
GMPLS Extensions for Dynamic Trunking
draft-cheng-gmpls-dynamic-trunking-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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."
To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
Abstract
Currently the GMPLS signaling requires to include a "LSP Encoding
Type" in the Generalized Label Request ([GMPLS-SIG]), which indicates
the encoding of the LSP being requested. Upon receiving a RSVP PATH
message or CR-LDP REQUEST message that contains a Generalized Label
Request, a LSR must verify if the receiving and transmitting interface
can support the LSP. In particular on the transmitting side, the node
either finds an interface that has the same switching class, among
other requirements, or it may use a FA-LSP, i.e., another class of
switching.
In a GMPLS network which provides multi-services, it is not efficient
nor scalable to statically configure each interface with a given
siwtching class. Further more, the primary benefit of FA-LSP is for
scaling the MPLS TE as a whole but it may be too heavy a mechanism
to solve switching capability problem in a local context.
This document describes a mechanism to dynamically create an
interface on the transmitting side of a LSR with the desirable
switching class if not already exists, upon receiving a LSP setup
request message that contains a Generalized Label Request. We call
such a feature as dynamic trunking in the rest of the document.
Table of Contents
1.0 Introduction ....................................................... 1
2.0 Routing Enhancements ............................................... 2
2.1 Dynamic Trunk and its Advertisement ............................ 2
2.1.1 Traffic Engineering Parameters ........................... 2
2.1.1.1 Link Type (OSPF Only) ........................... 2
2.1.1.2 Link ID (OSPF Only) ............................. 2
2.1.1.3 Local and Remote Interface IP Addresses ......... 2
2.1.1.4 Outgoing and Incoming Interface Identifiers ..... 3
2.1.1.5 Traffic Engineering Metric ...................... 3
2.1.1.6 Maximum Bandwidth ............................... 3
2.1.1.7 Unreserved Bandwidth ............................ 3
2.1.1.8 Resource Class/Color ............................ 3
2.1.1.9 Link Multiplex Capability ....................... 3
2.1.1.10 Maximum LSP Bandwidth ........................... 3
2.1.1.11 Link Protection Type ............................ 3
2.1.1.12 Link Descriptor ................................. 3
2.1.1.13 Shared Risk Link Group (SRLG) ................... 4
2.1.1.14 Dynamic Trunk Multiplex Capability (DTMC) ....... 4
2.1.1.14.1 OSPF DTMC sub-TLV .................... 4
2.1.1.14.2 IS-IS DTMC sub-TLV ................... 4
2.1.2 Advertisement for Dynamic Trunk .......................... 4
2.2 Dynamic TE Link and its Advertisement .......................... 5
2.3 Dynamic Trunking and Link Bundling ............................. 5
2.4 LSP Path Selection Consideration ............................... 5
3.0 Signaling Enhancements ............................................. 6
3.1 Restrictions ................................................... 6
3.2 Additional Handling ............................................ 7
4.0 LMP Enhancements ................................................... 7
4.1 Additional flag to the LMP Capability TLV ...................... 8
4.2 Additional LMP Message Types ................................... 8
4.3 Create Dynamic Trunk ........................................... 8
4.3.1 CreateDynamicTrunk Message (MsgType = 22) ................ 8
4.3.2 CreateDynamicTrunkAck Message (MsgType = 23) ............. 9
4.3.3 CreateDynamicTrunkNack Message (MsgType = 24) ............ 10
4.4 Add Link Messages .............................................. 10
4.4.1 AddLink Message (MsgType = 25) ........................... 10
4.4.1.1 TE Link TLV ...................................... 11
4.4.1.2 Data Link TLV .................................... 11
4.4.1.3 Data Link Creation Sub-TLV ....................... 11
4.4.2 AddLinkAck Message (MsgType = 26) ........................ 11
4.4.3 AddLinkNack Message (MsgType = 27) ....................... 11
4.5 Delete Link Messages ........................................... 12
4.5.1 DeleteLink Message (MsgType = 28) ........................ 12
4.5.1.1 TE Link TLV ...................................... 12
4.5.1.2 Data Link TLV .................................... 13
4.5.2 DeleteLinkAck Message (MsgType = 29) ..................... 13
4.5.3 DeleteLinkNack Message (MsgType = 30) .................... 13
5.0 Security Considerations ............................................ 13
6.0 References ......................................................... 14
7.0 Author's Addresses ................................................. 14
1.0 Introduction
In general, a TE link between a pair of physically adjacent LSRs needs
to be configured with a given switching multiplex capability type
assigned before it can be used to carry LSPs with the associated
classes. The LMP ([GMPLS-LMP]) may be used to manage all the TE
links between two neighboring LSRs.
A TE link with a particular switching class that inter-connect two
neighboring LSRs may also be created dynamically driven by the need,
i.e., when a LSP setup message arrives. When such a TE link is
created, its switching class is set to be the same as that of the
LSP. The setting of other characteristics of the TE link is a local
policy issue, but at the end of this, the LSP must be able to ride
on the TE link that just created.
After the dynamic TE link being created, it must be treated as a
normal TE link that is created by static configuration, including
link bundling, managed by LMP, advertised by IGP, etc. In particular,
a TE link dynamically created shall be used to carry other LSPs with
the associated switching class as described in the [GMPLS-HIER].
When a dynamically created TE link no longer carries any LSP, it may
be deleted and the associated resources released at the two neighbor
LSRs. This procedure is referred as garbage collection. A timer
may be used to trigger the garbage collection action once the TE
link no longer carries LSP.
The creation and deletion of a dynamic TE link shall be accomplished
by the LMP with additional mechanisms.
For a LSR that is capable of creating dynamic TE link, it may
advertise such a capability using IGP. This can be achieved by adding
additional mechanisms in the GMPLS-capable IGP, i.e. the
OSPF ([GMPLS-OSPF]) and ISIS ([GMPLS-ISIS]). The advertisement
includes the raw bandwidth that is available to be used for dynamic
trunking purpose, along with the set of switching multiplex
capabilities that the LSR is capable of, or willing to be
associating with dynamic TE links. We refer the object that associated
with such an advertisement as "dynamic trunk". A dynamic trunk is
associated with a given set of bandwidth like a regular TE link,
but is incapable of carrying LSP directly. One or more TE links
may be created dyanmically using the resources that associated
with a single dynamic trunk. When a dynamic TE link is created or
deleted within a dynamic trunk, the advertisement for the dynamic
trunk may be updated by the IGP.
A LSR, when performing path computation, may use conventional TE
links, forwading adjacencies (FA-LSP), and now also dynamic trunks.
[Page 1]
If a dynamic trunk is chosen, it must be noted in the LSP setup
request for the associated hop so that a dynamic TE link can be
created when the LSP setup request travels to the node that
advertising the dynamic trunk.
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].
2.0 Routing Enhancements
In this section we describe enhancements to the OSPF and IS-IS
that required to support the dynamic trunking feature, including
the advertisement for the dynamic trunk (Section 2.1), the
advertisement for the dynamic TE link (Section 2.2), and the path
computation that includes dynamic trunks (Section 2.4).
2.1 Dynamic Trunk and its Advertisement
In addition to the advertisements for the regular TE links as
described in the GMPLS IGPs ([GMPLS-OSPF] and [GMPLS-ISIS]), a dynamic
trunking capable LSR may also advertise the dynamic trunking
capability. Each dynamic trunking advertisement is associated with
a given pair of adjacent LSRs. For a given pair of adjacent LSRs,
the number of dynamic trunking advertisements is determined by
the local policy.
2.1.1 Traffic Engineering Parameters
The format of advertisement for a dynamic trunk is similar to that
of a regular TE link as described in the following sections.
2.1.1.1 Link Type (OSPF Only)
The Link Type of a dynamic trunk is set to "point-to-point".
2.1.1.2 Link ID (OSPF Only)
The Link ID is set to the Router ID of the adjacent LSR.
2.1.1.3 Local and Remote Interface IP Addresses
A dynamic trunk may be either a numbered or unnumbered. If is
numbered, the Local Interface IP Address is set to OSPF local
interface IP address or IS-IS IPv4 interface address that associated
with the dynamic trunk. The remote Interface IP address is set to
OSPF remote interface IP address or IS-IS IPv4 neighbor address
that associated with the dynamic trunk. The association between
a dynamic trunk and the set of IP addresses is a local matter.
For a unnumbered dynamic trunk, these two fields must be set to zero.
[Page 2]
2.1.1.4 Outgoing and Incoming Interface Identifiers
A dynamic trunk may be either a numbered or unnumbered. If is
unnumbered, there must be a 32-bit number on each LSR that uniquely
identify a dynamic trunk on a LSR, and this number is used as
the value of Outgoing Interface Identifier. Via LMP, the Outgoing
Interface Identifier on the other end of the dynamic trunk is
leanred and is used as the value of Incoming Interface Identifier.
For a numbered dynamic trunk, these two fields must be set to zero.
2.1.1.5 Traffic Engineering Metric
By default, the TE metric on a dynamic trunk is set to a very large
value so that it will only be possibly used as a last resort. The
actual setting for the TE metric is a local matter.
2.1.1.6 Maximum Bandwidth
The Maximum Bandwidth of a dynamic trunk is set via configuration,
which indicates the capacity of the raw bandwidth that may be used
to create dynamic TE links within. This value is set to the same
as the Maximum LSP bandwidth at the lowest priority (see the
Section 2.1.1.10).
2.1.1.7 Unreserved Bandwidth
By default, the Unreserved Bandwidth of all priority levels are
set to the Maximum Bandwidth.
2.1.1.8 Resource Class/Color
By default, a dynamic trunk has no color, but may be changed via
configuration.
2.1.1.9 Link Multiplex Capability
For the advertisement of a dynamic trunk, this is replaced by the
Dynamic Trunk Multiplex Capability (DTMC), see the Section 2.1.1.14.
2.1.1.10 Maximum LSP Bandwidth
The Maximum LSP Bandwidth of each priority is set via configuration,
and each of them indicates the capacity of the raw bandwidth that
may be used to create dynamic TE links within.
2.1.1.11 Link Protection Type
The protection type of a dynamic trunk is set via configuration.
2.1.1.12 Link Descriptor
The Link Descriptor is not included in the advertisement for a
dynamic trunk.
[Page 3]
2.1.1.13 Shared Risk Link Group (SRLG)
The SRLG type of a dynamic trunk is set via configuration.
2.1.1.14 Dynamic Trunk Multiplex Capability (DTMC)
This is a new sub-TLV added to the OSPF and IS-IS to support the
dynamic trunking enhancement and is a sub-TLV of the Link TLV.
The value of the DTMC includes a two-octet which is a bit vector as
defined as the following:
Bits Multiplex Capabilities
----- ----------------------
0x8000 Packet-Switch Capable-1 (PSC-1)
0x4000 Packet-Switch Capable-1 (PSC-2)
0x2000 Packet-Switch Capable-1 (PSC-3)
0x1000 Packet-Switch Capable-1 (PSC-4)
0x0800 Layer-2 Switch Capable (L2SC)
0x0400 Time-Division-Multiplex capable (TDM)
0x0200 Lambda-Switch Capable (LSC)
0x0100 Fiber-Switch Capable (FSC)
Rest bits Reserved
A bit in the value field, if set, indicates that one or more TE
links may be dynamically created with that switching multiplex
capability, and with the bandwidth allocated from the dyanmic trunk
that advertised. Note multiple bits may be set for a dynamic trunk.
2.1.1.14.1 OSPF DTMC sub-TLV
The code point of the OSPF Dyanmic Trunk Multiplex Capability
sub-TLV is as the follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 17 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multiplex Capability | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field is set to 4, and the Multiplex Capability contains
a bit vector as described as in the Section 2.1.1.14 above.
2.1.1.14.2 IS-IS DTMC sub-TLV
The code point of the IS-IS Dyanmic Trunk Multiplex Capability
sub-TLV is as the follows:
Type - 21
Length - two octets.
Value - two octets as described as in the Section 4.1.1.14.
[Page 4]
2.1.2 Advertisement for Dynamic Trunk
A dynamic trunk may only be advertised by a dynamic trunking capable
LSR. A dynamic trunk is always bi-directional in the sense that
any TE link dynamically created within can carry LSP that is either
bi-directional or uni-directional. Therefore, the two adjacent LSRs
must all advertise a dynamic trunk in their associated context before
that dynamic trunk can be used to create TE links.
When a TE link is created or deleted using the bandwidth within a
dynamic trunk, the advertisement for the dynamic trunk may be refreshed.
The initial bandwidth assigned to a dynamic trunk and the policy to
re-advertising are both local matter.
2.2 Dynamic TE Link and its Advertisement
A dynamic TE link is used in the same context of routing and signaling
as a regular TE link. The set of TE parameters is set according to
the specification as described in the [GMPLS-OSPF] and [GMPLS-ISIS],
for OSPF and IS-IS, respectively, used for the IGP.
There are some considerations in regarding the dynamic TE link as
stated as follows:
1) It is recommended that a dynamic TE link is always advertised
as a unnumbered link.
2) The Incoming Interface Identifier of a TE link is obtained
via LMP.
3) The setting of the Maximum LSP Bandwidth is determined by the
local policy, but must be at least as big as the LSP that
induced the dynamic TE link.
4) The Link Multiplex Capability is set to the one that associated
with the LSP Encoding Type contained in the GMPLS signaling
request.
5) Some of the TE parameters such as TE metric, Shared Risk Link
Group, Resource Class/Color, Link Protection Type, etc., may be
inherited from the associated dynamic trunk where the bandwidth
is allocated from. They may be changed via configuration just
like a regular TE link.
2.3 Dynamic Trunking and Link Bundling
A dynamic trunk is always advertised explicitly. The link bundling
mechanism as described in the ([GMPLS-BUNDLE]) must not be applied
on a dynamic trunk, but may be applied to a dynamic TE link.
[Page 5]
2.4 LSP Path Selection Consideration
A dynamic trunk is advertised by the two adjacent LSRs just like
a regular TE link. The dynamic trunk may be used in the LSP path
selection procedure in the same context as a regular TE link except:
1) A dynamic trunk may only be considered when there is no other
exsting TE links available between two adjacent nodes. This is
in the consideration of conserving the dynamic trunking
resources in the network.
2) If a dynamic trunk is chosen and included in the Explicit
Route Object (ERO), the proper references must be included
so that the local node understands a dynamic TE link needs
to be created. The proper references are either IP addresses
on a numbered dynamic trunk, or interface identifiers on a
unnumbered link.
3) Zero, one or more dynamic trunks may be included in a single ERO,
with each, if presented, corresponds to a pair of adjacent LSRs
that the LSP as requested traversing.
3.0 Signaling Enhancements
In this section we describe enhancements to the GMPLS signaling
protocols that required to support the dynamic trunking.
The dynamic trunk is advertised by IGP, and may be chosen by the
ingress LSR that includes it in the ER object just like a regular
TE link. Therefore there is no need for a special indication in
the GMPLS signaling protocols when a dyanmic trunk is included
in the ER object, nor any code point changes required.
3.1 Restrictions
There are three restrictions for the use of the dynamic trunk
in the MPLS signaling request messages as follows:
1) The inclusion of any dynamic trunk in the GMPLS signaling
setup request message is allowed only if the Generalized Label
Request Object is included ([GMPLS-SIG], [GMPLS-SIG],
[GMPLS-RSVP]).
The Generalized Label Request Object contains the LSP Encoding
type that is needed to determine the multiplex capability of
the TE link that is going to be dynamically created using
the bandwidth on the dynamic trunk.
2) The inclusion of a dynamic trunk in the GMPLS signaling
setup request message must be associated with a strict hop,
but not a loose hop.
[Page 6]
3) The inclusion of a dynamic trunk in the GMPLS signaling
setup request message can only be associated with a numbered
link or an unnumbered link, but not an abstract node.
For RSVP, a dynamic trunk is specified in one of the three
possible way:
1) IPv4 prefix ([RSVP-TE])
2) IPv6 prefix ([RSVP-TE])
3) unnumbered link ([UNNUM-RSVP])
For CR-LDP, a dynamic trunk is specified in one of the three
possible way:
1) IPv4 prefix ([CR-LDP])
2) IPv6 prefix ([CR-LDP])
3) unnumbered link ([UNNUM-CRLDP])
3.2 Additional Handling
When a LSR receives a LSP setup request that contains an ER
object, the processing rules as specified in the associated
signaling specifications are performed as usual. In addition,
if the next hop is associated with a dynamic trunk that is still
valid as the LSR previously advertised, the LSR needs to
create a TE link that inter-connects itself and the next hop LSR,
with the set of TE parameters as described in the Section 2.2.
Onece the dynamic creation of the TE link is successful, the original
call setup request can then be forwarded to the next hop as usual.
The creation of the dynamic TE link can be achieved by the LMP
with enhancements as described in the Section 4.0. This document
does not preclude other mechanisms however.
4.0 LMP Enhancements
4.1 Additional flag to the LMP Capability TLV
A new flag is added to the LMP capability TLV as follows:
0x04 Dynamic Trunking Procedure
Refer to the Section 9.4.1.2 of [GMPLS-LMP] for the existing
LMP capability flags.
The dynamic trunking capability must be a negotiable (N=1)
parameter, and only when both adjacent nodes are capable of
performing this extended LMP procedure, the IGP can then
advertise the dynamic trunk as described in the Section 4.1.
If the negotiation on this procedure is successful, the
following new messages may be exchanged between the two nodes:
[Page 7]
CreateDynamicTrunk (Section 4.3.1)
CreateDynamicTrunkAck (Section 4.3.2)
CreateDynamicTrunkNack (Section 4.3.3)
AddLink (Section 4.4.1)
AddLinkAck (Section 4.4.2)
AddLinkNack (Section 4.4.3)
DeleteLink (Section 4.5.1)
DeleteLinkAck (Section 4.5.2)
DeleteLinkNack (Section 4.5.3)
4.2 Additional LMP Message Types
The following new message types are added to the LMP.
22 = CreateDynamicTrunk
23 = CreateDynamicTrunkAck
24 = CreateDynamicTrunkNack
25 = AddLink
26 = AddLinkAck
27 = AddLinkNack
28 = DeleteLink
29 = DeleteLinkAck
30 = DeleteLinkNack
For the definition of existing LMP message types, refer to the
Section 9.1 of the [GMPLS-LMP].
4.3 Create Dynamic Trunk
4.3.1 CreateDynamicTrunk Message (MsgType = 22)
A CreateDynamicTrunk is sent over the control channel and its
purpose is to make a suggestion to the neighboring peer to
create a dynamic trunk.
The format of the CreateDynamicTrunk message is as follows:
<CreateDynamicTrunk Message> ::= <Common Header> <CreateDynamicTrunk>
The CreateDynamicTrunk object has the following format:
[Page 8]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Dynamic Trunk Id / Local Interface IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Dynamic Trunk Id / Remote Interface IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DTMC | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits
When combined with the CCId, the MessageId field uniquely
identifies a message. This value is incremented and only
decreases when the value wraps. This is used for message
acknowledgement in the CreateDynamicTrunkAck and
CreateDynamicTrunkNack messages.
Local Dynamic Trunk Id or Local Interface IP Address : 32 bits
This is either the Local Dynamic Trunk Id or the Local Dynamic
Trunk IP Address, depending on the flag setting.
Remote Dynamic Trunk Id or Remote Interface IP Address : 32 bits
This is either the Remote Dynamic Trunk Id or the Remote
Dynamic Trunk IP Address, depending on the flag setting.
If the value set to 0, the local node has no knowledge of
the remote node.
BitRate: 32 bits
This is the bit rate in bytes per second which specifies
the available bandwidth of the dynamic trunk.
DTMC: 16 bits
This is the flags for Dynamic Trunk Multiplex Capability, refer
to the Section 4.1.1.14.
Flags: 16 bits
There is only one flag currently defined:
0x0001 Link type
If this bit is set, the dynamic trunk is numbered, and
otherwise is unnumbered.
[Page 9]
4.3.2 CreateDynamicTrunkAck Message (MsgType = 23)
A CreateDynamicTrunkAck is sent over the control channel and its
purpose is to acknowledge the creation of a dynamic trunk between
the two nodes.
The format of the CreateDynamicTrunkAck message is as follows:
<CreateDynamicTrunkAck Message> ::=
<Common Header> <CreateDynamicTrunkAck>
The CreateDynamicTrunkAck object has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.3 CreateDynamicTrunkNack Message (MsgType = 24)
A CreateDynamicTrunkNack is sent over the control channel and its
purpose is to deny the creation of a dynamic trunk between the two
nodes.
The format of the CreateDynamicTrunkNack message is as follows:
<CreateDynamicTrunkNack Message> ::=
<Common Header> <CreateDynamicTrunkNack>
The CreateDynamicTrunkNack object has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4 Add Link Messages
4.4.1 AddLink Message (MsgType = 25)
The AddLink messsage is used to add a data link dynamically with
bandwidth allocated from a dynamic trunk. A data link added may
either be a port or a component link, and may be included within
an existing or a new TE link between the two nodes.
[Page 10]
The format of the AddLink message is as follows:
<AddLink Message> ::= <Common Header> <AddLink>
The AddLink object has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (AddLink TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits
When combined with the CCId, the MessageId field uniquely
identifies a message. This value is incremented and only
decreases when the value wraps. This is used for message
acknowledgement in the AddLinkAck and AddLinkNack messages.
4.4.1.1 TE Link TLV
The definition and format of the TE link TLV are defined in the
Section 9.7.1.1 of [GMPLS-LMP].
4.4.1.2 Data Link TLV
The definition and format of the data link TLV are defined in the
Section 9.7.1.2 of [GMPLS-LMP].
4.4.1.3 Data Link Creation Sub-TLV
The Data Link Creation Sub-TLV is TLV Type=7 and is defined as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 7 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BitRate: 32 bits
This is the bit rate in bytes per second which specifies
the initial bandwidth of the data link.
4.4.2 AddLinkAck Message (MsgType = 26)
The AddLinkAck message is sent over the control channel and its
purpose is to acknowlodge the addition of a new data link between
the two nodes.
[Page 11]
The format of the AddLinkAck message is as follows:
<AddLinkAck Message> ::= <Common Header> <AddLinkAck>
The AddLinkAck object has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4.3 AddLinkNack Message (MsgType = 27)
The AddLinkNack message is sent over the control channel and its
purpose is to deny the addition of a new data link between the two
nodes.
The format of the AddLinkNack message is as follows:
<AddLinkNack Message> ::= <Common Header> <AddLinkNack>
The AddLinkNack object has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.5 Delete Link Messages
4.5.1 DeleteLink Message (MsgType = 28)
The DeleteLink messsage is used to delete a data link. A data link
added may either be a port or a component link.
The format of the DeleteLink message is as follows:
<DeleteLink Message> ::= <Common Header> <DeleteLink>
The DeleteLink object has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (DeleteLink TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MessageId: 32 bits
When combined with the CCId, the MessageId field uniquely
identifies a message. This value is incremented and only
decreases when the value wraps. This is used for message
acknowledgement in the DeleteLinkAck and DeleteLinkNack
messages.
[Page 12]
4.5.1.1 TE Link TLV
The definition and format of the TE link TLV are defined in the
Section 9.7.1.1 of [GMPLS-LMP].
4.5.1.2 Data Link TLV
The definition and format of the data link TLV are defined in the
Section 9.7.1.2 of [GMPLS-LMP].
4.5.2 DeleteLinkAck Message (MsgType = 29)
A DeleteLinkAck is sent over the control channel and its
purpose is to deny the deletion of a data link between the two nodes.
The format of the DeleteLinkAck message is as follows:
<DeleteLinkAck Message> ::= <Common Header> <DeleteLinkAck>
The DeleteLinkAck object has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.5.3 DeleteLinkNack Message (MsgType = 30)
A DeleteLinkNack is sent over the control channel and its
purpose is to deny the deletion of a data link between the two nodes.
The format of the DeleteLinkNack message is as follows:
<DeleteLinkNack Message> ::= <Common Header> <DeleteLinkNack>
The DeleteLinkNack object has the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MessageId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.0 Security Considerations
Security issues are not discussed in this document.
[Page 13]
6.0 References
[CR-LDP] Jamoussi, et al., "Constraint-Basd LSP Setup using
LDP", Internet Draft, draft-ietf-mpls-cr-ldp-05.txt,
February 2001.
[GMPLS-BUNDLE] Kompella/Rekhter/Berger,
"Link Bundling in MPLS Traffic Engineering",
Internet Draft,
draft-kompella-mpls-bundle-05.txt, February 2001.
[GMPLS-CRLDP] Ashwood-Smith, et al, "Generalized MPLS Signaling
- CR-LDP Extensions", Internet Draft,
draft-ietf-mpls-generalized-cr-ldp-02.txt,
April, 2001.
[GMPLS-HIER] Kompella/Rekhter, "LSP Hierarchy with MPLS TE",
Internet Draft,
draft-ietf-mpls-lsp-hierarchy-02.txt,
February, 2000.
[GMPLS-ISIS] Kompella, et al, "IS-IS Extensions in Support
of Generalized MPLS", Internet Draft,
draft-ietf-isis-gmpls-extensions-02.txt,
February 2001.
[GMPLS-LMP] Lang/Mitra, et al, "Link Management Protocol (LMP)",
Internet Draft, draft-ietf-mpls-lmp-02.txt,
March, 2001.
[GMPLS-OSPF] Kompella, et al, "OSPF Extensions in Support
of Generalized MPLS", Internet Draft,
draft-kompella-ospf-gmpls-extensions-01.txt,
February 2001.
[GMPLS-RSVP] Ashwood-Smith, et al, "Generalized MPLS
Signaling - RSVP-TE Extensions", Internet Draft,
draft-ietf-mpls-generalized-rsvp-te-02.txt,
April, 2001.
[GMPLS-SIG] Ashwood-Smith, et al, "Generalized MPLS -
Signaling Functional Description", Internet Draft,
draft-ietf-mpls-generalized-signaling-04.txt,
May 2001.
[Page 14]
[RSVP-TE] Awduche, et al, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", Internet Draft,
draft-ietf-mpls-rsvp-ls--tunnel-08.txt,
February 2001.
[UNNUM-CRLDP] Kompella/Rekhter/Kullberg, "Signaling Unnumbered
Links in CR-LDR", Internet Draft,
draft-ietf-mpls-crldp-unnum-01.txt, February, 2000.
[UNNUM-RSVP] Kompella/Rekhter, "Signaling Unnumbered Links in
RSVP-TE", Internet Draft,
draft-ietf-mpls-rsvp-unnum-01.txt, November, 2000.
7.0 Authors' Addresses
Dean Cheng
Polaris Networks Inc.
6810 Santa Teresa Blvd.
San Jose, CA 95119
Phone: +1 408 284 8061
Email: dcheng@polarisnetworks.com
[Page 15]
