One document matched: draft-oki-ccamp-gtep-00.txt
CCAMP Working Group Eiji Oki
Internet Draft Daisaku Shimazaki
Expiration Date: October 2004 Kohei Shiomoto
April 2004
Generalized Traffic Engineering Protocol
draft-oki-ccamp-gtep-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.''
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.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This draft describes a generalized traffic engineering protocol (GTEP).
GTEP is a protocol that communicates between a Constrained Shortest Path
First (CSPF) engine and a GMPLS controller (GMPLS CNTL). A GMPLS CNTL is
a controller that handles GMPLS and MPLS protocols such as routing and
signaling protocols and controls a GMPLS node. The CSPF engine provides
a function of traffic engineering, which calculates LSP routes and
judges whether a new lower-layer LSP should be established.
E. Oki et al. [Page 1]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
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 RFC-2119.
1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to sup-
port various switching technologies. GMPLS enables us to control a
packet switching network, layer 2 switching networks such as asyn-
chronous transfer mode (ATM) and Ethernet, TDM networks such as syn-
chronous digital hierarchy/synchronous optical network (SDH/SONET),
lambda and fiber networks all at once.
A GMPLS-based multi-region network architecture is addressed in [MRN].
Multi-region traffic engineering in GMPLS networks increases network
resource efficiency, because all the network resources are taken into
account at the same time. However, in GMPLS multi-region network envi-
ronments, traffic engineering becomes more complicated, compared with
that in single-region network environments. For example, let us consider
hierarchical label switched paths (LSPs) [LSP-HIERARCHY], where a
higher-layer LSP uses a lower-layer LSP as a TE-link. When the higher-
layer LSP is setup, it is necessary to judge whether new lower-layer
LSPs SHOULD be established for forwarding adjacency LSPs (FA-LSPs), or
existing lower-layer LSPs SHOULD be used for FA-LSPs. It is not realis-
tic that the LSP route calculation engine, or constrained shortest path
first (CSPF) engine, that performs multi-region traffic engineering
(MRTE) with several constraints is implemented into all the node. More-
over, judgements such as whether new LSPs SHOULD be established, or
existing LSPs SHOULD be used depends on network providers' traffic-engi-
neering policy. Network providers want to have own traffic engineering
engine. From vendors' points of view, it is not desirable to implement
the CSPF engine that considers all the requirements from network
providers. A complicated CSPF engine may also cause the node to degrade
its processing capablity. Therefore, it is reasonable to separate the
CSPF engine from a GMPLS controller that handles GMPLS protocols.
This draft describes a generalized traffic engineering protocol (GTEP).
GTEP is a protocol that communicates between the CSPF engine engine and
the GMPLS controller (GMPLS CNTL).
2. GTEP Overview
E. Oki et al. [Page 2]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
2.1. GTEP Common Definitions
All GTEP packets are run over TCP with a GTEP port number The GTEP port
number is TBA (to be assigned) by IANA. For the time being, a private
port number, which is in the range between 49152 and 65535, is used.
+------------------+
| +------+ |
| |RSVP | |
| |module| |
+-----------+ | +------+ |
|CSPF engine+---------||---------+ |
+-----------+ GTEP | +----+ +------+ |
| |LSDB+--+ OSPF | |
| +----+ |module| |
| +------+ |
+------------------+
GMPLS CNTL
Figure 1 Communication between CSPF engine and GMPLS CNTL with GTEP.
GTEP is a protocol that communicates between an CSPF engine and a GMPLS
CNTL. A GMPLS CNTL is a controller that handles GMPLS and MPLS proto-
cols and controls a GMPLS node.
The GMPLS CNTL handles GMPLS protocols such as signaling and routing
protocols. Figure 1 depicts the GMLS CNTL structure that includes a
RSVP module and a OSPF moudle with a Link State Database (LSDB)
The CSPF engine provides a function of traffic engineering, which calcu-
lates LSP routes and judges whether a new lower-layer LSP SHOULD be
established.
Applicability of CSPF Engine is as follows. For single-layer networks,
the CSPF engine provides LSP routes considering several constraints.
For multi-region networks, a function of multi-region traffic engineer-
ing, which calculates LSP routes and judges whether a new lower-layer
LSP SHOULD be established.
The detail functions of the GMPLS CNTL and the CSPF engine based on GTEP
are descrbied in the following subsections.
Note that functions that are related to the GTEP procedures getting the
information on LSDB are optional. This is because several alternatives
to have topology data in the CSPF engine can be considered.
E. Oki et al. [Page 3]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
2.2. GMPLS CNTL Function
A GMPLS CNTL is a controller that handles GMPLS and MPLS protocols and
controls a GMPLS node. When the GMPLS CNTL tries to setup a new LSP, or
receives a Path message from the previous hop node, it requires a CSPF
engine to give the LSP route to it. The CSPF engine calculates the LSP
route and gives it to the GMPLS CNTL. The GMPLS CNTL establishes the
LSP according to the route suggested by the CSPF engine.
The CSPF engine requires the GMPLS CNTL to setup a lower-layer LSP if it
is necessary. In this case, the GMPLS CNTL tries to setup the lower-
layer LSP and returns the result whether the LSP setup succeeds to the
CSPF engine. When the LSP setup succeeds, the result includes LSP_TUN-
NEL_IF_ID for the FA LSP.
When a Link State Database (LSDB) in the GMPLS CNTL is updated, it sends
the updated LSDB information to the CSPF engine. When the GMPLS CNTL is
requested to give the LSDB information, it sends the latest LSDB infor-
mation to the CSPF engine.
2.3. CSPF Engine Function
CSPF engine gives the GMPLS CNTL an LSP route when the LSP route is
requested by the GMPLS CNTL. The CSPF engine calculates the LSP route by
using Traffic Engineering Database (TED). TED in the CSPF engine is cre-
ated by using the information of the LSDB in the GMPLS CNTL.
The CSPF engine requires the GMPLS CNTL to setup a lower-layer LSP if it
is necessary. In this case, the GMPLS CNTL tries to setup the lower-
layer LSP and returns the result whether the LSP setup succeeds to the
CSPF engine. When the LSP setup succeeds, the result includes LSP_TUN-
NEL_IF_ID for a FA LSP. The CSPF engine creates a route of the
requested higher-layer LSP by using LSP_TUNNEL_IF_ID as interfaces of
TE-links and send the route to the GMPLS CNTL.
When a Link State Database (LSDB) in the GMPLS CNTL is updated, it sends
the updated LSDB information to the CSPF engine. According to the LSDB
update, the CSPF engine also updates the TED. When the CSPF engine is
booted, it requests the information of LSDB to the GMPLS CNTL. The
GMPLS CNTL sends the information of LSDB to the CSPF engine. Then, the
CSPF engine creates TED.
3. GTEP Procedure
In this section, typical sequences are desribed.
E. Oki et al. [Page 4]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
3.1. CSPF Engine Boot Sequence
CSPF engine GMPLS CNTL
| |
| ConfigRequest Message |
|-------------------------------->|
| |
| ConfigResponse Message |
|<--------------------------------|
| |
| LsRequest Message |
|-------------------------------->|
| |
| LsResponse Message |
|<--------------------------------|
| |
Figure 2 CSPF engine boot sequence.
Step 1. The CSPF engine is booted.
Step 2. The CSPF engine sends ConfigRequest Message to the GMPLS CNTL to
request configuration in the GMPLS CNTL.
Step 3. The GMPLS CNTL sends ConfigResponse Message to the CSPF engine
to give the configuration.
Step 4. The CSPF engine sends LsRequest Message to the GMPLS CNTL to
request the LSDB information in the GMPLS CNTL.
Step 5. The GMPLS CNTL send LsResponse Message to the CSPF engine to
give the LSDB information.
Note that steps 1 and 2 may be omitted when the CSPF engine wants to
synchronize only the LSDB information with the GMPLS CNTL.
3.2. Link-state update sequence
CSPF engine GMPLS CNTL
| |
| LsUpdate Message |
|<--------------------------------|
| |
Figure 3 Link-state update sequence.
Step 1. The GMPLS CNTL sends LsUpdate Message to CSPF engine to give the
updated LSAs, which includes LSAs that are written or deleted in the
LSDB, with the LsUpdate message. LSAs that are not changed in the LSDB
E. Oki et al. [Page 5]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
SHOULD NOT be sent to the CSPF engine.
3.3. LSP Setup Sequence for Single Layer Case
CSPF engine GMPLS CNTL
| |
| RouteRequest Message |
|<--------------------------------|
| |
| RouteResponse Message |
|-------------------------------->|
| |
Figure 4 LSP setup sequence for single layer case.
Step 1. The GMPLS CNTL is requested to setup an LSP.
Step 2. The GMPLS CNTL sends RouteRequest Message to the CSPF engine to
ask it to give the LSP route. Request Message.
Step 3. The CSPF engine sends RouteResponse Message to the GMPLS CNTL to
give the LSP route. If the result is "success", RouteResponse Message
includes the route. The specified route is formatted as Explicit Route
Object that is carried in a Path message. If the result is "failure",
RouteResponse Message includes an error code that indicates why the
result is "failure", and optically includes suggested routes but does
not competely satisfy the constraints and suggested alternative con-
straints that enable to find a route [MPLS-COMP]. In MPLS networks,
[MPLS-COMP] describes examples of alternative constraints such as band-
width and protection type. In GMPLS networks, alternative constraints
such as switching type, encoding type, GPID, and SRLG are extended.
3.4. LSP Setup Sequence for Two Layer Case
CSPF engine GMPLS CNTL
| |
| RouteRequest Message |
|<--------------------------------|
| |
| LspSetupRequest Message* |
|-------------------------------->|
| |
| LspSetupResponse Message* |
|<--------------------------------|
| |
| RouteResponse Message |
E. Oki et al. [Page 6]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
|-------------------------------->|
| |
*The LspSetupRequest/LspSetupResponse Messages appear only when the
lower-layer LSP needs to be established.
Figure 5 LSP setup sequence for two layer case.
Step 1: The GMPLS CNTL is requested to setup an higher-layer LSP. The
node that is connected to the GMPLS CNTL MAY be an ingress node, or MAY
be an transit node from the high-layer LSP's point of view.
Step 2: If at least one condition in the following is satisfied, go to
Step 3. Otherwise, go to Step 7.
1. Explicit Route is not specified.
2. When Explicit Route is specified, the next hop node is specified as Loose.
3. When Explicit Route is specified and the next hop node is specified as "Strict",
there is no TE-link that satisfies constraints such as bandwidth between the node
and the next hop node.
Step 3. The GMPLS CNTL sends RouteRequest Message to the CSPF engine to
request a route of the higher-layer LSP.
Step 4. The CSPF engine requires the GMPLS CNTL to setup a lower-layer
LSP if it is necessary. Otherwise, go to Step 6. The GMPLS CNTL judges
that it is necessary to establish a new lower-layer LSP in either of the
following cases.
1. There is no TE-link that satisfies constraints such as bandwidth between
the node and the next hop node, or
2. GMPLS CNTL finds a shorter route with the new lower-layer LSP than
the shortest route on the existing low-layer-LSP topology.
Step 5. The GMPLS CNTL tries to setup the lower-layer LSP and returns
the result whether the LSP setup succeeds to the CSPF engine. When the
LSP setup succeeds, the result includes LSP_TUNNEL_IF_ID for the FA LSP.
Step 6. The CSPF engine sends RouteResponse Message that specifies the
route of the higher-layer LSP to the GMPLS CNTL if the result is "suc-
cess". The specified route is formatted as Explicit Route Object that
is carried in a Path message. The specified route is formatted as
Explicit Route Object that is carried in a Path message. If the result
is "failure", RouteResponse Message includes an error code that indi-
cates why the result is "failure", and optically includes suggested
routes but does not competely satisfy the constraints and suggested
alternative constraints that enable to find a route [MPLS-COMP]. In MPLS
networks, [MPLS-COMP] describes examples of alternative constraints such
as bandwidth and protection type. In GMPLS networks, alternative con-
straints such as switching type, encoding type, GPID, and SRLG are
E. Oki et al. [Page 7]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
extended.
Step 7. Signaling procedure starts as an ingress node, or continues as
an transit node for the higher-layer LSP, according to the route speci-
fied by Explicit Route Object.
4. GTEP Message
4.1. Common Header and Common Trailer
In addition to the TPC header and standard IP header, all GTEP messages
have the following common header and common trailer.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | GTEP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Message body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Marker (32 bits, ASCII CODE "GTEP") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Common Header and Common Trailer
The Reserved field should be sent as zero and ignored on receipt. All
values are defined in network byte order (i.e., big-endian byte order).
Version: 8 bits. Protocol version number. This is version 1.
Message Type: 8 bits. The following values are defined.
1 = RouteRequest Message
2 = RouteResponse Message
3 = RouteRequestCancel Message
4 = LspSetupRequest Message
5 = LspSetupResponse Message
6 = LsUpdate Message
7 = LsRequest Message
8 = LsResponse Message
9 = ConfigRequest Message
10 = ConfigResponse Message
E. Oki et al. [Page 8]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
Result: 8 bits. A value of "NoSuccessAck" indicates that the request
message does not expect a response if the outcome is successful, and a
value of "AckAll" indicates that a response is expected if the outcome
is successful. In both cases a failure response MUST be generated if the
request fails. In a response message, the result field can have two val-
ues: "Success" and "Failure". The "Success" and "Failure" results indi-
cate success and failure responses, respectively. All messages that
belong to the same success response will have the same Transaction Iden-
tifier. The following values are defined.
1 = NoSuccessAck
2 = AckAll
3 = Success
4 = Failure
Code: 8 bits. Field gives further information concerning the result in a
response message. It is mostly used to pass an error code in a failure
response but can also be used to give further information in a success
response message or an event message. In a request message, the code
field is not used and is set to zero.
Transaction ID: 24 bits. Used to associate a request message with its
response message. For request messages, the controller may select any
transaction identifier. For response messages, the transaction identi-
fier is set to the value of the transaction identifier from the message
to which it is a response. For event messages, the transaction identi-
fier SHOULD be set to zero. The Transaction Identifier is not used, and
the field is not present, in the adjacency protocol.
GTEP Length: 16 bits. Length of the GTEP message including its header
fields, defined GTEP message body, and marker field. It is expressed by
byte.
Marker: 32 bits. This 32-bit filed contains ASCII CODE "GTEP". With the
maker field and the length, it is judged whether GTEP messages are cor-
rectly sent and received. If the marker field does not contain ASCII
CODE "GTEP", it indicates that the GTEP message has a format error. In
this case, the TCP connection is disconnected, and the CSPF, which is a
client, sets up the TCP connection with the GMPLS CNTL, which is a
server, again.
4.2. GTEP Message Format
GTEP messages are built using objects. Each object is identified by its
Object Class and Class-type. Each object has a name, which is always
capitalized in this document.
E. Oki et al. [Page 9]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
All values are defined in network byte order (i.e., big-endian byte
order). The format of the GTEP object is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class | C-Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ (object contents) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 GTEP Object
Class: 8 bits. The Class indicates the object type. Each object has a
name, which is always capitalized in this document.
C-Type: 8 bits. Class-type, unique within an Object Class. Values are
defined in Section 5.
Length: 8 bits. Length of the GTEP object including its header fields
and defined GTEP object contents. It is expressed by byte.
4.2.1. RouteRequest Message
The RouteRequest message is used when the GMPLS CNTL requests the CSPF
engine to give the GMPLS CNTL an LSP route. In the common header, the
result is set to 2 and the transaction ID is set to a non-zero value.
The contents of the RouteRequest message are built using GTEP objects.
The format of the RouteRequest message is as follows:
<RouteRequest Message> ::= <Common Header>
[<TIME_VALUE>]
<DESTINATION_IP_ADDRESS>
<LABEL_REQUEST>
<BANDWIDTH>
<PROTECDTION>
[<PRIMARY_PATH_ROUTE>]
[<SECONDARY_PATH_ROUTE>]
TIME_VALUE is an option and indicates an allowable waiting time from
when the RouteRequest message is sent to the CSPF engine until when the
RouteResponse message is received from the CSPF engine. If TIME_VALUE
is not included, a default allowable waiting time configured by the
GMPLS CNTL is used. If the allowable waiting time expires before the
RouteResponse message is received, the waiting state is released.
E. Oki et al. [Page 10]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
DESTINATION_IP_ADDRESS indicates a destination IP address of the LSP
route that is requested to be calculated from the node connected to the
GMPLS CNTL. DESTINATION_IP_ADDRESS MAY NOT be the same as the destina-
tion address of the LSP. DESTINATION_IP_ADDRESS MAY be a router id of a
transit node. In a transit node, when an explicit route object in the
Path message includes "loose" for a part of the LSP route, the GMPLS
CNTL asks the CSPF engine to give the exact route of the LSP that is
specified as "loose" by the explicit route in the Path message. On the
other hand, in the transit node, when an explicit route object strictly
specifies the next hop node but there is no direct TE-link to the next
hop node that satisfies the constraints, the GMPLS CNTL sends the
RouteRequest message to the CSPF engine by setting DESTINA-
TION_IP_ADDRESS as the next hop node.
LABEL_REQUEST includes LSP encoding type, switching type, and informa-
tion on the LSP direction, which is uni-direction or bi-direction. By
using these values, the type of LSP that should be setup is described.
BANDWIDTH indicates the LSP bandwidth.
PROTECTION indicates the protection type of LSP that should be setup.
PRIMARY_PATH_ROUTE is an option. It is set when the GMPLS CNTL requests
the CSPF engine for the route of the secondary LSP that is disjoint from
the primary LSP. SECONDARY_PATH_ROUTE is an option. It is set when the
GMPLS CNTL requests the CSPF engine for the route of the secondary LSP.
4.2.2. RouteResponse Message
The RouteResponse message is used when the GMPLS CNTL gives the CSPF
engine an LSP route that is requested by the CSPF engine. In the common
header, the result is set to 3 (success) or 4 (failure), and the trans-
action ID is set to the value that is set by the RouteRequest message.
The contents of the RouteResponse message are built using GTEP objects.
The format of the RouteResponse message is as follows:
<RouteResponse Message> ::= <Common Header>
[<PRIMARY_PATH_ROUTE>]
[<SECONDARY_PATH_ROUTE>]
When the result is set to 3 (success), the RouteResponse message
includes either <PRIMARY_PATH_ROUTE> or <SECONDARY_PATH_ROUTE>, or both
of them, according to the request of the RouteRequest message.
In the common header, when the result is set to 4 (failure), the code is
defined as follows:
E. Oki et al. [Page 11]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
Code = 1: Format error of RouteRequest message
Code = 2: Failure on the calculation for the requested LSP route.
4.2.3. RouteCancel Message
The RouteCancel message is used when the GMPLS CNTL cancels the request
that is sent to the CSPF engine as the RouteRequest message. When the
CSPF engine receives the RouteCancel message from the GMPLS CNTL, the
CSPF stops the LSP route calculation. In the common header,
the result is set to 1, and the transaction ID is set to the value that
is set by the RouteRequest message. The contents of the RouteCancel mes-
sage are built using GTEP objects. The format of the RouteCancel message
is as follows:
<RouteCancel Message> ::= <Common Header>
4.2.4. LspSetupRequest Message
The LspSetupRequest message is used when the CSPF engine request the
GMPLS CNTL to setup the lower-layer LSP if it is necessary to setup the
higher-layer LSP, whose route is requested by the RouteRequest message.
In the common header, the result is set to 2, and the transaction ID is
set to a non-zero value. The contents of the LspSetupRequest message are
built using GTEP objects. The format of the LspSetupRequest message is
as follows:
<LspSetupRequest Message> ::= <Common Header>
[<TIME_VALUE>]
<DESTINATION_IP_ADDRESS>
<LABEL_REQUEST>
<BANDWIDTH>
<PROTECTION>
<PRIMARY_PATH_ROUTE>
[<SECONDARY_PATH_ROUTE>]
TIME_VALUE is an option and indicates an allowable waiting time from
when the LspSetupRequest message is sent to the GMPLS CNTL until when
the LspSetupRequest message is receded from the GMPLS CNTL. If
TIME_VALUE is not included, a default allowable waiting time configured
by the MPLS engine is used. If the allowable waiting time expires before
the LspSetupResponse message is received, the waiting state is released.
DESTINATION_IP_ADDRESS indicates a destination IP address of the LSP
that is requested to be setup. The node that is connected to the GMPLS
node is a source node.
E. Oki et al. [Page 12]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
LABEL_REQUEST includes LSP encoding type, switching type, and informa-
tion on the LSP direction, which is uni-direction or bi-direction. By
using these values, the type of LSP that should be setup is described.
BANDWIDTH indicates the LSP bandwidth. The GMPLS CNTL SHOULD setup the
LSP whose bandwidth is equal to or more than the value indicated by
BANDWIDTH.
PROTECTION indicates the protection type of LSP that should be setup.
PRIMARY_PATH_ROUTE is mandatary. It indicates the route of the primary
LSP. SECONDARY_PATH_ROUTE is an option. It is set when the CSPF engine
requests the secondary LSP in addition to the primary LSP.
4.2.5. LspSetupResponse Message
The LspSetupResponse message is used when the GMPLS CNTL gives the CSPF
engine the result of the LSP setup that is requested by the CSPF engine.
In the common header, the result is set to 3 (success) or 4 (failure),
and the transaction ID is set to the value that is set by the LspSe-
tupRequest message. The contents of the LspSetupResponse message are
built using GTEP objects. The format of the LspSetupResponse message is
as follows:
<LspSetupResponse Message> ::= <Common Header>
<INGRESS_LSP_TUNNEL_IF_ID>
<EGRESS_LSP_TUNNEL_IF_ID>
When the result is set to 3 (success), the LspSetupResponse message
includes both INGRESS_LSP_TUNNEL_IF_ID and EGRESS_LSP_TUNNEL_IF_ID.
In the common header, when the result is set to 4 (failure), both
INGRESS_LSP_TUNNEL_IF_ID and EGRESS_LSP_TUNNEL_IF_ID are not included in
the LspSetupResponse Message and the code is defined as follows:
Code = 1: Format error of LspSetupRequest message
Code = 2: Failure on the requested LSP setup.
4.2.6. LsUpdate Message
The LsUpdate message is used when the GMPLS CNTL sends the CSPF engine
the updated LSAs. In the common header, the result is set to 1, and the
transaction ID is set to a non-zero value. The contents of the LsUpdate
message are built using GTEP objects. The format of the LsUpdate message
is as follows:
E. Oki et al. [Page 13]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
<LsUpdate Message> ::= <Common Header>
<LSA>
...
<LSA>
The GMPLS CNTL sends the CSPF engine only the updated LSAs, which
includes LSAs that are written or deleted in the Link State Database
(LSDB), with the LsUpdate message. LSAs that are not changed in the
LSDB SHOULD NOT be sent to the CSPF engine. The deleted LSA is recog-
nized by the MaxAge. The LSA is identified by the link state type, the
link state ID, and the advertising router. The CSPF overwrites the
updated LSA as a new LSA in the database, if the updated LSA has the
same values of the link state type, the link state ID, and the advertis-
ing router in the database.
4.2.7. LsRequest Message
The LsRequest message is used when the CSPF engine requests the GMPLS
CNTL for all the LSAs that the GMPLS CNTL has. In other words, the LsRe-
quest message is used when the CSPF engine is booted, or the CSPF
engine's database has a problem and its database needs to be refreshed.
In the common header, the result is set to 2, and the transaction ID is
set to a non-zero value. The contents of the LsRequest message are built
using GTEP objects. The format of the LsRequest message is as follows:
<LsRequest Message> ::= <Common Header>
[<TIME_VALUE>]
TIME_VALUE is an option and indicates an allowable waiting time from
when the LsRequest message is sent to the GMPLS CNTL until when the
LsResponse message is received from the GMPLS CNTL. If TIME_VALUE is
not included, a default allowable waiting time configured by the MPLS
engine is used. If the allowable waiting time expires before the LsRe-
sponse message is received, the waiting state is released.
4.2.8. LsResponse Message
The ConfigResponse message is used when the GMPLS CNTL sends the CSPF
engine its configuration of the router. In the common header, the result
is set to 3 (success) or 4 (failure), and the transaction ID is set to
the value that is set by the ConfigRequest message. The contents of the
ConfigResponse message are built using GTEP objects. The format of the
ConfigResponse message is as follows:
<LsResponse Message> ::= <Common Header>
E. Oki et al. [Page 14]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
<LSA>
...
<LSA>
When the result is set to 3 (success), the GMPLS CNTL sends the CSPF
engine all the LSAs with the LsResponse. When the CSPF engine received
the LsResponse message, the LSA data in the CSPF engine is cleared if
any, it writes the LSAs carried by the LsResponse message in the CSPF-
engine database.
In the common header, when the result is set to 4 (failure), both LSAs
are not included in the LsResponse Message and the code is defined as
follows:
Code = 1: Format error of LspRequest message
Code = 2: There is no LSA in the GMPLS CNTL.
4.2.9. ConfigRequest Message
The ConfigRequest message is used when the CSPF engine requests the
GMPLS CNTL for the configuration of the router. In the common header,
the result is set to 2, and the transaction ID is set to a non-zero
value. The contents of the ConfigRequest message are built using GTEP
objects. The format of the ConfigRequest message is as follows:
<ConfigRequest Message> ::= <Common Header>
[<TIME_VALUE>]
TIME_VALUE is an option and indicates an allowable waiting time from
when the ConfigRequest message is sent to the GMPLS CNTL until when the
ConfigResponse message is received from the GMPLS CNTL. If TIME_VALUE
is not included, a default allowable waiting time configured by the MPLS
engine is used. If the allowable waiting time expires before the Confi-
gResponse message is received, the waiting state is released.
4.2.10. ConfigResponse Message
The ConfigResponse message is used when the GMPLS CNTL sends the CSPF
engine its configuration of the router. In the common header, the result
is set to 3 (success) or 4 (failure), and the transaction ID is set to
the value that is set by the ConfigRequest message. The contents of the
ConfigResponse message are built using GTEP objects. The format of the
ConfigResponse message is as follows:
<ConfigResponse Message> ::= <Common Header>
E. Oki et al. [Page 15]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
<ROUTER_ID>
When the result is set to 3 (success), the ConfigResponse message
includes ROUTER_ID.
In the common header, when the result is set to 4 (failure), ROUTER_ID
is not included in the ConfigResponse Message and the code is defined as
follows:
Code = 1: Format error of ConfigRequest message
Code = 2: Failure to get the router id.
5. GTEP Object
5.1. TIME_VALUE
Class=2.
The information carried in TIME_VALUE is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 TIME_VALUE
5.1.1. C-type=1.
Time Value: 32 bits. The time value indicates an allowable waiting time
from when the request message is sent at the CSPF engine/GMPLS CNTL
until when the LspSetupRequest message is received at the CSPF
engine/GMPLS CNTL. It is expressed by millisecond.
5.2. DESTINATION_IP_ADDRESS
Class=3.
The information carried in DESTINATION_IP_ADDRESS is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address/Router ID |
E. Oki et al. [Page 16]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 DESTINATION_IP_ADDRESS
5.2.1. C-type=1.
Destination IPv4 address: 32 bits. The destination IPv4 address is the
destination of the requested route, which is an interface or a router
ID. The destination IPv4 address MAY NOT be the LSP destination, when a
part of the LSP route is requested.
5.3. LABEL_REQUEST
Class=4.
The information carried in LABEL_REQUEST is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 LABEL_REQUEST
5.3.1. C-type=1.
LABEL_REQUEST includes LSP encoding type, switching type, and informa-
tion on the LSP direction, which is uni-direction or bi-direction.
LSP Encoding Type: 8 bits. See [RFC3471] for a description of parame-
ters.
Switching Type: 8 bits. See [RFC3471] for a description of parameters.
D: 1 bit. 0 indicates a uni-directional LSP. 1 indicates a bi-direc-
tional LSP.
5.4. BANDWIDTH
Class=5.
The information carried in BANDWIDTH is:
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
E. Oki et al. [Page 17]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11 BANDWIDTH
5.4.1. C-type=1.
Bandwidth: 32 bits. The bandwidth indicates the required bandwidth.
Bandwidth encodings are carried in 32 bit number in IEEE floating point
format (the unit is bytes per second). See [RFC3471] for a definition of
values to be used for specific signal types.
5.5. PROTECTION
Class=6.
The information carried in PROTECTION is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R |RT | Reserved | LSP Flags | Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: Reserved
RT: Route Type
Figure 12 PROTECTION
5.5.1. C-type=1.
Route Type: 4 bits.
0: The route of the primary LSP is requested.
1: The route of the secondary LSP is requested.
2: The routes of the primary and secondary LSPs are requested.
3: This value MUST NOT be used. A format error occurs if it is used.
When Route Type=0, SECONDARY_PATH_ROUTE MUST be included in the
RouteRequest message. When Route Type=1, PRIMARY_PATH_ROUTE MUST be
included in the RouteRequest message. When Route Type=2, PRI-
MARY_PATH_ROUTE and SECONDARY_PATH_ROUTE MUST NOT be included in the
RouteRequest message.
Other values is the same definition as those described in [GMPLS_RECOV-
ERY_E2E].
E. Oki et al. [Page 18]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
5.6. PATH_ROUTE
Class=7. PATH_ROUTE consists of one or more Path route subobjects.
The information carried in PRTH_ROUTE is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Path route subobjects ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13 PATH_ROUTE
5.6.1. C-type=1, PRIMARY_PATH_ROUTE.
It indicates the primary route. It uses the following formats, which are
IPv4 numbered subobject and unnumbered subobject.
The information carried in IPv4 numbered subobject is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14 IPv4 numbered subobject
L: 1 bit. 0 indicates the strict hop. 1 indicates the loose hop.
Type: 7 bits. 0x01: An IPv4 address, which is either numbered interface
address or Router ID, is specified.
Length: 8 bits. Length of all the IPv4 numbered subobject. It is
expressed by byte. The value is always set to 8.
The information carried in unnumbered subobject is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E. Oki et al. [Page 19]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15 Unnumbered subobject
L: 1 bit. 0 indicates the strict hop. 1 indicates the loose hop.
Type: 7 bits. 0x04: Unnumbered address.
Length: 8 bits. It indicates the length of all the unnumbered subobject.
It is expressed by byte. The value is always set to 12.
5.6.2. C-type=2, SECONDARY_PATH_ROUTE.
It indicates the secondary route. It uses the same format as PRI-
MARY_PATH_ROUTE.
5.7. LSP_TUNNEL_IF_ID
Class=10.
5.7.1. C-type=1, INGRESS_LSP_TUNNEL_IF_ID.
It indicates the TUNNEL_IF_ID of the setup LSP at the ingress.
The information carried in LSP_TUNNEL_IF_ID is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16 LSP_TUNNEL_IF_ID
The format is based on TUNNEL_IF_ID described in [RFC3477]. See
[RFC3477] for a description of parameters.
E. Oki et al. [Page 20]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
5.7.2. C-type=2, EGRESS_LSP_TUNNEL_IF_ID.
It indicates the TUNNEL_IF_ID of the setup LSP at the egress. It uses
the same format as INGRESS_LSP_TUNNEL_IF_ID.
5.8. LSA
Class=11.
The information carried in LSA is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| LSA contents |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17 LSA
5.8.1. C-type=1.
LSA includes all the LSA types.
Area ID: 32 bits. It indicates the area ID of the LSA.
Other values is the same definition as those described in
[RFC2328][RFC2370], except for the LS checksum and the length. The CSPF
engine ignores the LS checksum. It indicates the length including 20
bytes LSA header, except for the area ID, and the LSA contents. It is
expressed by byte.
E. Oki et al. [Page 21]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
5.9. ROUTER_ID
Class=12.
The information carried in ROUTER_ID is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18 ROUTER_ID
5.9.1. C-type=1.
Router ID: 32 bits. It indicates the route ID.
6. References
[RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional
Description," RFC 3471 , Jan. 2003.
[RFC3473] P. Ashwood-Smith et al, "Generalized MPLS Signaling - RSVP-TE
Extensions," RFC 3473, Jan. 2003.
[RFC2338] J. Moy, "OSPF Version 2," RFC 2328.
[RFC2370] R. Coltun, "The OSPF Opaque LSA Option," RFC 2370.
[RFC3630] D. Katz et al., "Traffic Engineering (TE) Extensions to OSPF
Version 2," RFC 3630.
[GMPLS_OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of
Generalized MPLS," IETF draft, draft-ietf-ccamp-ospf-gmpls-exten-
sions-09.txt, Dec. 2002. (working in progress)
[GMPLS_RECOVERY_E2E] J.P. Lang et al., "RSVP-TE Extensions in support of
End-to-End GMPLS-based Recovery," IETF draft, draft-ietf-ccamp-gmpls-
recovery-e2e-signaling-00.txt, Mar. 2004. (working in progress)
[RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links in
Resource ReSerVation Protocol -Traffic Engineering (RSVP-TE)," RFC 3477.
(working in progress)
[MRN] D. Papadimitriou et al., "Generalized MPLS Architecture for Multi-
E. Oki et al. [Page 22]
E. Oki et al. draft-oki-ccamp-gtep-00.txt April 2004
Region Networks, draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt, Feb.
2004. (working in progress)
[LSP-HIERARCHY] K. Kompella and Y. Rekhter, "LSP Hierarchy with General-
ized MPLS TE," draft-ietf-mpls-lsp-hierarchy-08.txt, Sep. 2002. (working
in progress)
[MPLS-COMP] JP Vasseur et al., "RSVP Path computation request and reply
messages," IETF draft, draft-vasseur-mpls-computation-rsvp-03, June
2002.
7. Authors' Address
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp
Daisaku Shimazaki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Email: shimazaki.daisaku@lab.ntt.co.jp
Kohei Shiomoto
NTT
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
Email: shiomoto.kohei@lab.ntt.co.jp
E. Oki et al. [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-23 21:06:33 |