Internet DRAFT - draft-ietf-forces-tcptml
draft-ietf-forces-tcptml
Hormuzd Khosravi
Internet Draft Shuchi Chawla
Document: draft-ietf-forces-tcptml-04.txt Intel Corp.
Expires: January 2007 Furquan Ansari
Working Group: ForCES Lucent Tech.
Jon Maloy
Ericsson
July 2006
TCP/IP based TML (Transport Mapping Layer) for ForCES protocol
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in
progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 [2].
Abstract
Khosravi, et al Expires January 2007 [Page 1]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
This document defines the IP based TML (Transport Mapping Layer) for
the ForCES protocol. It explains the rationale for choosing the
transport protocols and also describes how this TML addresses all
the requirements described in the Forces [3] requirements and
ForCES protocol [5] document.
Table of Contents
1. Definitions.....................................................3
2. Introduction....................................................3
3. Protocol Framework Overview.....................................4
3.1.1. The PL layer................................................5
3.1.2. The TML layer...............................................5
4. TML Overview....................................................5
4.1. Rationale for using TCP and DCCP..............................6
4.2. Separate Control and Data channels............................6
4.3. Reliability...................................................8
4.4. Congestion Control............................................8
4.5. Security......................................................8
4.6. Addressing....................................................8
4.7. Prioritization................................................9
4.8. HA Decisions..................................................9
4.9. Encapsulations Used..........................................10
5. TML Messaging..................................................10
6. TML Interface to Upper layer Protocol..........................10
6.1. TML Service Interface Overview...............................10
6.2. Protocol Initialization and Shutdown Model...................11
6.2.1. Protocol Initialization....................................11
6.2.2. Protocol Shutdown..........................................13
6.3. Multicast Model..............................................14
6.4. Broadcast Model..............................................17
7. Security Considerations........................................17
7.1. TLS Usage for Securing TML...................................17
7.2. IPSec Usage for securing TML.................................18
8. IANA Considerations............................................18
9. Manageability..................................................18
10. References....................................................18
10.1. Normative References........................................18
10.2. Informative References......................................18
11. Acknowledgments...............................................19
Appendix A. TML Service Interface................................19
A.1. TML Initialize.............................................19
A.2. TML Channel Open...........................................20
A.3. TML Channel Close..........................................21
A.4. TML Channel Write..........................................22
A.5. TML Channel Read...........................................23
A.6. TML Multicast Group Join...................................25
Khosravi, et al Expires January 2007 [Page 2]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
A.7. TML Multicast Group Leave..................................25
Authors' Addresses...............................................26
1.
Definitions
The following definitions are taken from [3], [5]
ForCES Protocol - While there may be multiple protocols used within
the overall ForCES architecture, the term "ForCES protocol" refers
only to the protocol used at the Fp reference point in the ForCES
Framework in RFC3746 [4]. This protocol does not apply to
CE-to-CE communication, FE-to-FE communication, or to communication
between FE and CE managers. Basically, the ForCES protocol works in
a master-slave mode in which FEs are slaves and CEs are masters.
ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
architecture that defines the ForCES protocol messages, the protocol
state transfer scheme, as well as the ForCES protocol architecture
itself (including requirements of ForCES TML (see below)).
Specifications of ForCES PL are defined by this document.
ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
ForCES protocol architecture that specifically addresses the
protocol message transportation issues, such as how the protocol
messages are mapped to different transport media (like TCP, IP, ATM,
Ethernet, etc), and how to achieve and implement reliability,
multicast, ordering, etc. This document defines an IP based ForCES
TML.
2.
Introduction
The ForCES (Forwarding and Control Element Separation) working group
in the IETF is defining the architecture and protocol for separation
of control and forwarding elements in network elements such as
routers. [3
.], [4] define both architectural and protocol
requirements for the communication between CE and FE. The ForCES
protocol layer [5] describes the protocol specification. It is
envisioned that the ForCES protocol would be independent of the
interconnect technology between the CE and FE and can run over
multiple transport technologies and protocol. Thus a Transport
Mapping Layer (TML) has been defined in the protocol framework that
will take care of mapping the protocol messages to specific
transports. This document defines the IP based TML for the ForCES
protocol layer. It also addresses all the requirements for the TML
including security, reliability, etc.
Khosravi, et al Expires January 2007 [Page 3]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
3.
Protocol Framework Overview
The reader is referred to the Framework document [4], and in
particular sections 3 and 4, for architectural overview and where
and how the ForCES protocol fits in. There may be some content
overlap between the ForCES protocol draft [5] and this section in
order to provide clarity.
The ForCES protocol constitutes two pieces: the PL and TML layer.
This is depicted in Figure 1 below.
+------------------------------------------------
| CE PL layer |
+------------------------------------------------
| CE TML layer |
+------------------------------------------------
^
|
ForCES | (i.e. Forces data + control
PL | packets )
messages |
over |
specific |
TML |
encaps |
and |
transport |
|
v
+------------------------------------------------
| FE TML layer |
+------------------------------------------------
| FE PL layer |
+------------------------------------------------
Figure 1: ForCES Interface
The PL layer is in fact the ForCES protocol. Its semantics and
message layout are defined in [5]. The TML Layer is necessary to
connect two ForCES PL layers as shown in Figure 1 above.
Both the PL and TML layers are standardized by the IETF. While only
one PL layer is defined, different TMLs are expected to be
standardized. To interoperate the TML layer at the CE and FE are
expected to be of the same definition.
Khosravi, et al Expires January 2007 [Page 4]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
On transmit, the PL layer delivers its messages to the TML layer.
The TML layer delivers the message to the destination TML layer(s).
On reception, the TML delivers the message to its destination PL
layer(s).
3.1.1.The PL layer
The PL is common to all implementations of ForCES and is
standardized by the IETF [5]. The PL layer is responsible for
associating an FE or CE to an NE. It is also responsible for
tearing down such associations. An FE uses the PL layer to throw
various subscribed-to events to the CE PL layer as well as respond
to various status requests issued from the CE PL. The CE configures
both the FE and associated LFBs attributes using the PL layer. In
addition the CE may send various requests to the FE to activate or
deactivate it, reconfigure it’s HA parameterization, subscribe to
specific events etc.
3.1.2.The TML layer
The TML layer is essentially responsible for transport of the PL
layer messages. The TML is where the issues of how to achieve
transport level reliability, congestion control, multicast,
ordering, etc. are handled. All TMLs will deliver a standard set of
services and capabilities to the PL; the PL may use any available
TML. The different TMLs each could implement things differently
based on capabilities of underlying media and transport.
However, since all TMLs will support a standardized interface,
interoperability is guaranteed as long as both endpoints support the
same TML. All ForCES Protocol Layer implementations should be
portable across all TMLs, because all TMLs have the same top edge
semantics.
4.
TML Overview
The TML consists of two connections between the CE and FE over which
the protocol messages are exchanged. One of the connections is
called the control channel, over which control messages are
exchanged, the other is called data channel over which external
protocol packets, such as routing packets will be exchanged. The
control channel is a TCP connection; the data channel is a DCCP
connection. The TCP and DCCP connections will use unique server
port numbers for each of the channels. In addition to this, this TML
will provide mechanisms to prioritize the messages over the
different channels.
Khosravi, et al Expires January 2007 [Page 5]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
Some of the rationale for choosing these transport mechanisms as
well as explanation of how they meet the TML requirements is
explained below. The ForCES protocol defines requirements to be met
by the TML. However, the requirements in the draft do not always
differentiate between control versus data messaging. The assumption
is that the requirements for messaging over the data channel are a
subset of those specified for control messaging. When such an
assumption is made, it is explicitly specified and the justification
for the same stated.
4.1.Rationale for using TCP and DCCP
For control messaging, TCP meets all the reliability requirements
(no losses, no data corruption, no re-ordering of data) for the
ForCES protocol/TML and also provides congestion control mechanism,
which is important to meet the scalability requirement. In addition,
it helps with interoperability since TCP is a well-understood,
widely deployed transport protocol. Using TCP also enables this TML
and the protocol to work seamlessly in single hop and multihop
scenarios.
The reliability requirements for the data channel messages are
different from that of the control messages [3] i.e. they don’t
require strict reliability in terms of retransmission, etc. However
congestion control is important for the data channel because in case
of DoS attacks, if an unreliable transport such as UDP is used for
the data traffic, it can more easily overflow the physical
connection, overwhelming the control traffic with congestion. Thus
we need a transport protocol that provides congestion control but
does not necessarily provide full reliability. Datagram Congestion
Control Protocol (DCCP) [9], which is on the RFC track is a
transport protocol that exactly meets this requirement.
4.2.Separate Control and Data channels
The ForCES NEs are subject to Denial of Service (DoS) attacks
[Requirements Section 7 #15]. A malicious system in the network can
flood a ForCES NE with bogus control packets such as spurious RIP or
OSPF packets in an attempt to disrupt the operation of and the
communication between the CEs and FEs. In order to protect against
this situation, the TML uses separate control and data channels for
communication between the CEs and FEs. Figure 2 below illustrates
the different communication channels between the CEs and the FEs. As
an example, the communication channels for support of High
Availability with redundant CEs are also included. The setup of
these channels would be dependent on the High Availability model
used in the NE.
Khosravi, et al Expires January 2007 [Page 6]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
ACTIVE CE STANDBY CE
+-------------------+ +-------------------+
| CE: PL | | CE: PL |
+-------------------+ +-------------------+
| CE: TML | | CE: TML |
+-------------------+ +-------------------+
| CE: TCP/DCCP | | CE: TCP/DCCP |
+-------------------+ +-------------------+
| | | | | | | | | |
| . | . | . | . | .
| | | | | | | | | |
| . | . | . | . | .
| | | | | | Cc1’ Cd1’ Cc2’ Cd2…Ccn’ Cdn’
| . | . | .
+-Cc1-----+ | | | | +-.-.-.-.-.Cdn.-+
| +-Cd1-.-.+ | . +--------Ccn---+ |
| | | | | .
| . +Cc2+ . | |
| | | +Cd2+ | .
| . | | | |
+------------+ +------------+ +------------+
|FE: TCP/DCCP| |FE: TCP/DCCP| . . . |FE: TCP/DCCP|
+------------+ +------------+ +------------+
| FE: TML | | FE: TML | | FE: TML |
+------------+ +------------+ +------------+
| FE: PL | | FE: PL | | FE: PL |
+------------+ +------------+ +------------+
FE1 FE2 FEn
\-------------V------------/
FE 1+1 Redundancy
Legend:
---- Cc# : Unicast Control Channel between Active CE and FE#
-.-. Cd# : Unicast Data Channel between Active CE and FE#
---- Cc#’: Unicast Control Channel between Standby CE and FE#
-.-. Cd#’: Unicast Data Channel between Standby CE and FE#
Figure 2: CE-FE Communication Channels
The data channel carries IP packets from the network needed by the
CE, such as RIP, OSPF packets as outlined in Requirements [3]
Section 7 #10, which are carried in ForCES Packet Redirect messages
[5], between the CEs and FEs. All the other ForCES messages, which
are used for configuration/capability exchanges, event notification,
Khosravi, et al Expires January 2007 [Page 7]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
etc, are carried over the control channel. The data channel is set
up only after the control channel is set up.
4.3.Reliability
TCP provides the reliability (no losses, no data corruption, no re-
ordering of data) required for ForCES protocol control messages.
As mentioned earlier, as per [3], strict reliability is not a
requirement for payload carried over the data channel. Hence, the
use of DCCP is adequate for the data channel.
4.4.Congestion Control
TCP provides congestion control needed to satisfy this requirement
for the control channel.
DCCP provides congestion control to satisfy this requirement for the
data channel. DCCP supports two congestion control mechanisms – TCP
like congestion control specified with a CCID of 2 and TFRC
congestion control specified with a CCID of 3. The DCCP channel may
use either of these mechanisms; the CE and the FE may be configured
with the mechanism to be used. The default CCID to be used if none
is configured is CCID 2 which provides TCP like congestion control.
4.5.Security
The TML channel can be secured in multiple ways. The default mode is
to support the “no security”, a mode that is commonly used when it
is determined that securing the ForCES channel is not needed (e.g.
closed-box scenario). For scenarios where security is important, the
TML uses either the TLS [6] or the IPSec [15] mechanisms to secure
the channel(s). The security mode selection is normally done through
configuration on either ends. Note that the TML will operate
correctly only when both the ends are configured with the same
security mechanism. The security mode used by the CE and FE is
dependent on the deployment scenario as per the ForCES protocol
requirements draft [3
.]. Please see section 7 on security
considerations for more details.
4.6.Addressing
This TML uses addressing provided by IP layer.
For unicast addressing/delivery of control messages, it uses the TCP
connection between the CE and FE. For multicast/broadcast
Khosravi, et al Expires January 2007 [Page 8]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
addressing/delivery of control messages, this TML uses multiple TCP
connections between the CE and FEs.
Additionally, the TML layer maintains the mapping between the PL
layer addresses and the channel descriptors assigned by the TML
layer. The PL layer is unaware of these descriptors; the PL layer
only uses the PL layer addresses for all communication with the TML
layer.
For unicast addressing/delivery over the data channel, it uses the
DCCP connection between the CE and FE. Multicast/broadcast
addressing and delivery is not supported over the data channel; data
messages may only be sent from the CE to the FEs using unicast
FEIds. If multicast support is required, the higher level protocol
being carried over the data channel is responsible for it.
4.7.Prioritization
This TML provides prioritization of messages sent over control
channel as compared to the data channel. This has also been found to
be useful in face of DoS attacks on the protocol. Additionally the
TML can support multiple levels of prioritization for control
messages if it supports a multi-queue strategy. The scheduling
algorithm used at the TML layer would give preferential treatment to
higher priority messages. The scheduling algorithm used in the TML
layer is implementation dependent.
4.8.HA Decisions
The TML transports the heartbeat messages generated at the PL layer
to detect liveness of the CE/FE. The TML does not generate any
heartbeat messages of its own. The PL heartbeat messages are
carried over the control channel. For the data channel, the TML will
propagate any DCCP detected connectivity issues over the channel to
the PL layer. If the PL wishes to actively monitor the data
channel, it may do so by sending periodic redirect packets from the
CE to the FE. This details of this mechanism are however outside
the scope of the TML.
TML is responsible for keeping the control and data communication
channels up. It however does not have the authority to decide which
CE to set up the channels with. That is outside its control.
If a FE-CE communication channel goes down or connectivity is lost,
the following steps are taken by the TML layer:
- FE TML attempts to reestablish the communication channel
Khosravi, et al Expires January 2007 [Page 9]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
- If the FE TML is unable to reestablish the channel (after some
configured number of retries/timeout), it notifies the FE PL that
the channel is down.
- CE TML waits for the channel to be reestablished (since only the
FE can reestablish it) for some configured timeout prior to
notifying the CE PL that the channel is down. Alternatively, the
PL may detect the channel is down via the use of the PL generated
heartbeat messages.
If the control channel or data channel goes down, PL will control
initiation of a failover to a new CE – both control and data
channels will be reestablished with the new CE.
If an FE goes down and a standby FE exists for it, and it has
communication channels set up with the CE, the CE PL may start to
use the channels associated with the standby FE. This is not within
the scope of TML itself, but falls in the scope of High
Availability.
4.9.Encapsulations Used
There is no further message encapsulation of control and data
messages done at the TML layer. The PL generated control messages
are transported as is by the TML layer. The ForCES protocol control
messages are encapsulated with a TCP/IP header. The PL data messages
carried over the data channel are encapsulated in a DCCP header.
5.
TML Messaging
There is no TML layer messaging. TML only transports messages from
the PL layer.
6.
TML Interface to Upper layer Protocol
ForCES TML interfaces with an upper layer protocol, the PL Layer and
a lower layer protocol, TCP (in the case of TCP TML). This section
defines the interface to the upper layer protocol. This interface
should be used only as a guideline in implementing the API.
Additionally, although the current interface is defined mainly as a
synchronous interface, the interface may be implemented to be
asynchronous if desired.
6.1.TML Service Interface Overview
This section provides an overview of the TML service interface to
help with understanding the following sections on protocol behavior
Khosravi, et al Expires January 2007 [Page 10]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
with respect to initialization and multicast support. Note that
this is just a brief overview for understanding the protocol
initialization/shutdown sequences. It is by no means complete; the
complete service interface is being specified in a separate draft.
More details on this interface are specified in Appendix A.
tmlInit() – Enables establishment of communication channels
tmlOpen() – Opens one or more communication channels for control and
data messaging
tmlClose() – Closes one or more communication channels used for
control and data messaging
tmlWrite() – Write messages to a specific CE or FE
tmlRead() – Read messages from a specific CE or FE
tmlMulticastGroupJoin() – Request an FE to join a multicast group
tmlMulticastGroupLeave() - Request an FE to leave a multicast group
6.2.Protocol Initialization and Shutdown Model
In order for the peer PL Layers to communicate, the control and data
channels must be setup. This section defines a model for the setup
of the channels, using the TML interface defined above. In this
model, the peer TML Layers may establish the control and data
channels between the FE and the CE without the involvement of the PL
Layers, or if desired, the PL Layer may trigger the setup of the
channels; this is left as an implementation decision. Both modes
may also be supported within an implementation.
6.2.1.Protocol Initialization
The control channel must be established between the FE TML and the
CE TML for establishment of association to proceed. This channel
will be used for messages related to the association setup and
capability query. The data channel must be established no later
than the response from the FE to the CE Topology query message. The
following are the significant aspects associated with channel setup:
- A single call by the PL layer sets up the communication channels
for both control and data messaging to a specific FE. The call
specifies Unicast CE Id and attributes for control and data
channels.
- It is up to the TML layer whether to set up a single channel for
both control and data or distinct channels for control and data
Khosravi, et al Expires January 2007 [Page 11]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
- TML sets up the appropriate channels and allocates required
descriptors for the channels. TML layer maintains a mapping
between the Unicast FE/CE Id and the channel descriptors and
channel type (control versus data) it creates once the FEId/CEId
is known.
- There is no need for channel descriptors to be returned to the PL
layer at either the FE or the CE. PL Layer only uses the Unicast
FE/CE Id for read/write calls and specifies the type of message
(control versus data) to be read/written.
- If only one of the channels is setup successfully, the TML layer
will have to return appropriate status that specifies which
channel is setup successfully and which isn’t.
Figure 4 illustrates the initialization model where the PL layer via
an interface provided by the TML Layer, triggers the setup of the
control and data channels.
FE1 PL FE1 TML CE TML CE PL
| | | | \
/ | | | tmlInit() | |
FE | | | |<--------------| > CE Init/
Init/ < | | | | | Bootup
Bootup | | | | | /
\ | | | |
| tmlOpen(CeId) | | |
|-------------->| | | \
| |CtrlChan(Cc) Setup | | | Setup control
| |~~~~~~~~~~~~~~~~~~~~~~>| | | channel if not
| | | > already setup
| |CtrlChan(Cc) Setup Rsp | | |
| |<~~~~~~~~~~~~~~~~~~~~~~| | |
| CeId . [CcDes<ctrl>] | | |
| | | /
| | | |
| |DataChan(Cd) Setup | | | Setup data
| |~~~~~~~~~~~~~~~~~~~~~~>| | | channel if not
| | | | > already setup
| |DataChan(Cd) Setup Rsp | | |
| |<~~~~~~~~~~~~~~~~~~~~~~| | |
| CeId . [CcDes<ctrl>, | | |
| | CdDes<data>] | | /
| | | |
| <-- status | | |
| | | |
|tmlEvent(ChUp) | |tmlEvent(ChUp) |
|<--.--.--.--.--| |--.--.--.--.-->|
| | | |
| | Asso Setup Req | |
|---------------|-----------------------|-------------->|
| FeId . [CcDes<ctrl>, | \
Khosravi, et al Expires January 2007 [Page 12]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
| CdDes<data>] | | TML updates
| | > its mappings
| | | once FEId is
| | Asso Setup Rsp | | | available.
|<--------------|-----------------------|---------------| /
| | | |
| | Capability Query | |
|<--------------|-----------------------|---------------|
| | Capability Query Rsp | |
|---------------|-----------------------|-------------->|
| | | |
| | Topology Query | |
|<--------------|-----------------------|---------------|
| | Topology Query Rsp | |
|---------------|-----------------------|-------------->|
| | | |
| |STEADY STATE OPERATION | |
|<--------------|-----------------------|-------------->|
| | | |
Legend:
PL --------> PL : Protocol layer messaging
PL --------> TML: TML API
TML --.--.--> PL : Events/Notifications/Upcalls
TML ~~~~~~~~> TML: Internal protocol communication
Figure 4: Protocol Initialization (Channel Setup)
6.2.2.Protocol Shutdown
The control channel teardown must occur only after the association
teardown has occurred. The data channel teardown may occur no earlier
than the association teardown.
The PL Layer may shutdown control and data channels via invocation of
the tmlClose() API. When the PL layer shuts down the channels, the
channels are torn down; hence ForCES messaging between the CE and FE is
no longer possible over those channels. A tmlClose() results in both
control and data channels (regardless of whether they are implemented
as a single channel or distinct channels in the TML layer) being
shutdown; it is not possible to close just one of them. A subsequent
tmlOpen() triggers establishment of the channel. The channel(s) may be
shutdown by either the FE or the CE. If an FE initiates the shutdown,
it specifies the CE Id associated with the channel(s) to be shutdown.
If a CE initiates the shutdown, it specifies the FE Id associated with
the channel(s) to be shutdown. A channel shutdown by the FE is
illustrated in Figure 5 and a channel shutdown by the CE is illustrated
in Figure 6.
FE PL FE TML CE TML CE PL
| | | |
Khosravi, et al Expires January 2007 [Page 13]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
| |STEADY STATE OPERATION | |
|<--------------|-----------------------|-------------->|
| | Config Request | |
|<--------------|-----------------------|---------------|
| | Config Response | |
|---------------|-----------------------|-------------->|
| | | |
| | Association Teardown | |
|<--------------|-----------------------|---------------|
| | | |
| | | | \
|tmlClose(CeId) | | | | FE initiated:
|-------------->| | | > FE specifies CE
| <-- status | | | | Id associated
| | | | / with channel.
Legend:
PL --------> PL : Protocol layer messaging
PL --------> TML: TML API
TML --.--.--> PL : Events/Notifications/Upcalls
TML ~~~~~~~~> TML: Internal protocol communication
Figure 5: Protocol Shutdown: FE Initiated
FE PL FE TML CE TML CE PL
| | | |
| |STEADY STATE OPERATION | |
|<--------------|-----------------------|-------------->|
| | Config Request | |
|<--------------|-----------------------|---------------|
| | Config Response | |
|---------------|-----------------------|-------------->|
| | | |
| | Association Teardown | |
|<--------------|-----------------------|---------------|
| | | |
| | | | \
| | |tmlClose(FeId) | | CE initiated:
| | |<--------------| > FE specifies CE
| <-- status | | status --> | | Id associated
| | | | / with channel.
Legend:
PL --------> PL : Protocol layer messaging
PL --------> TML: TML API
TML --.--.--> PL : Events/Notifications/Upcalls
TML ~~~~~~~~> TML: Internal protocol communication
Figure 6: Protocol Shutdown: CE Initiated
6.3.Multicast Model
Khosravi, et al Expires January 2007 [Page 14]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
The TML layer provides support for multicast of control messages.
In the ForCES model, support is required to multicast to the FEs
from a CE; in this case, the CE is the source or root of the
multicast and the FEs are the leaves.
Support for multicast requires that a channel for supporting
multicast be opened between an FE and the CE. In the case of TCP
TML, the same channel is used for both unicast and multicast
messaging since multicast mode is simulated using unicast channels
in this case. Once the channel is open, a CE may request FEs to join
and leave specified multicast groups. Multicast support is CE-
initiated. FEs can join a multicast group only if the CE requests
them to join the group. TML maintains the mapping between PL layer
IDs and channel descriptors for multicast. The following are the
significant steps for adding or removing members from a multicast
group:
- CE PL communicates with FE PL for requesting the FE to join or
leave a multicast group.
- FE PL informs FE TML regarding the join or leave request.
- FE TML updates the multicast group information. It updates the
mapping between the FE Multicast Id and the channel descriptor to
be used for multicast for that FE. This mapping may be from
[Multicast FE Id] . [FE Id] . [Channel descriptor] or directly
from [Multicast FE Id] . [Channel descriptor]. This is
implementation dependent.
- FE PL responds to CE PL informing it of the status of the join or
leave request.
- If the join or leave request was successful, CE PL informs CE TML
regarding the update to the multicast group membership.
- CE TML updates the multicast group membership. It updates the
mapping between the FE Multicast Id and the set of channel
descriptors to be used for multicast to the FEs that are members
of this group. This mapping may be from [Multicast FE Id] . [Set
of FE Ids] . [Set of channel descriptors] or directly from
[Multicast FE Id] . [Set of channel descriptors]. This is
implementation dependent.
- There is no need for any descriptors to be returned to the PL
layer at either the FE or the CE. PL Layer only uses the
Multicast FE Id for write calls and specifies the type of message
(control versus data) to be written.
A tmlWrite() on a unicast FE Id results in a unicast message being
sent to the FE associated with the channel. A tmlWrite() on a
multicast FE Id results in multicast messaging. Figures 7 and 8
illustrate multicast scenarios with 2 FEs, FE1 and FE2. In Figure
7, the CE requests FE1 to join a multicast group. Although not
Khosravi, et al Expires January 2007 [Page 15]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
shown as a separate figure, if FE2 were to join the same group, the
join procedure would be the same as in Figure 7; it would result in
the multicast group membership being updated at the TML layer on the
CE to include FE2 in the group. In Figure 8, the CE requests FE1 to
leave the multicast group, thus resulting in only FE2 being a member
of the multicast group.
Multicast Scenario with FE1 joining group: New group created
FE1 PL FE1 TML CE TML CE PL
| | | |
| | | | \
| MC Grp Join Req (McId) | |
|<--------------|-------------------|---------------| | CE:PL Level multicast group
[TML | tmlJoin(McId) | | | | join request sent to each
updates |-------------->| | | | FE:PL that needs to be part
MC grp | McId = {FE1_ChDes} | | > of a multicast group, McId,
info] | | | | | where McId specifies a
| <-- status | | | | multicast group Id at the
| | | | | PL layer.
| MC Grp Join Rsp (status) | |
|---------------|-------------------|-------------->| /
| | | |
| | | | \
| | |tmlJoin(McId) | | TML updates multicast
| | |<--------------| | group membership. PL is
| | McId = {FE1_ChDes} | > only aware of PL layer
| | | | | multicast group Id, that is,
| | | status --> | | McId]
| | | | /
Figure 7: Multicast Support: FE1 Joins Group
Multicast Scenario with FE1 leaving group: Group membership updated
to exclude FE1
FE1 PL FE1 TML CE TML CE PL
| | | |
| | | | \
| MC Grp Leave Req (McId, FE1) | |
|<--------------|-------------------|---------------| | CE:PL Level multicast group
[TML | tmlLeave(McId)| | | | leave request sent to FE1:PL
removes |-------------->| | | | that needs to be removed
MC grp | McId = {} | | > from multicast group, McId,
info] | | | | | where McId specifies a
| <-- status | | | | multicast group Id at the
| | | | | PL layer.
| MC Grp Leave Rsp (status) | |
|---------------|-------------------|-------------->| /
| | | |
| | | | \
| | |tmlLeave(McId) | | TML removes FE1 from
| | |<--------------| | multicast group McId.
| | McId = {FE2_ChDes} | > That leaves only FE2
Khosravi, et al Expires January 2007 [Page 16]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
| | | | | in the group.
| | | status --> | |
| | | | /
Figure 8: Multicast Support: FE1 Leaves Group
6.4.Broadcast Model
The TML layer provides support for broadcast of control messages.
In the ForCES model, support is required to broadcast to the FEs
from a CE. The broadcast model is just a special case of multicast,
where all FEs are included. This TML does not support CE or NE
broadcast.
7.
Security Considerations
If the CE or FE are in a single box and network operator is running
under a secured environment then it is up to the network
administrator to turn off all the security functions. This is
configured during the pre-association phase of the protocol. This
mode is called “no security” mode of operation.
When the CEs, FEs are running over IP networks or in an insecure
environment, the operator has the choice of configuring either TLS
[6] or IPSec [15] to provide security. The security association
between the CEs and FEs MUST be established before any ForCES
protocol messages are exchanged between the CEs and FEs.
7.1.TLS Usage for Securing TML
This section is applicable for CE or FE endpoints that use the TML
with TLS [6] to secure communication.
Since CE is master and FEs are slaves, the FEs are TLS clients and
CEs are TLS server. The endpoints that implement TLS MUST perform
mutual authentication during TLS session establishment process. CE
must request certificate from FE and FE needs to pass the requested
information.
We recommend “TLS-RSA-with-AES-128-CBC-SHA” cipher suite, but CE or
FE may negotiate other TLS cipher suites. With this TML, TLS is used
only for the control channel while the data channel is left
unsecured since the data packets (e.g. routing protocol packets) may
contain their own security mechanisms. Further, TLS has not yet been
defined for usage with DCCP.
Khosravi, et al Expires January 2007 [Page 17]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
7.2.IPSec Usage for securing TML
This section is applicable for CE or FE endpoints that use the TML
with IPSec [15] to secure their respective communication. IPSec is
transparent to the higher-layer applications and can provide
security for any transport layer protocol. This mechanism is can be
used to secure just the control or both the control and the data
channel simultaneously.
8.
IANA Considerations
This TML needs to have a one well-defined TCP port number for
control messaging, which needs to be assigned by IANA. The control
port is referred to as the TCP_TML_CONTROL_PORT. Similarly, TML
requires one well-defined DCCP port number for data messaging. This
data port is referred to as the DCCP_TML_DATA_PORT.
9.
Manageability
TBD
10.
References
10.1.Normative References
1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026,
October 1996.
2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement
Levels", RFC2119 (BCP), IETF, March 1997.
3. Khosravi, et al., ’’Requirements for Separation of IP Control and
Forwarding”, RFC 3654, November 2003.
4. L. Yang, et al., ” ForCES Architectural Framework”, RFC 3746,
April 2004.
5. A. Doria, et al., ”ForCES protocol specification”, draft-ietf-
forces-protocol-06.txt, December 2005.
10.2.Informative References
6. Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P.
Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
Khosravi, et al Expires January 2007 [Page 18]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
7. Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436,
December 2002.
8. R. Stewart, et al., “Stream Control Transmission Protocol (SCTP)”,
RFC 2960, October 2000.
9. E. Kohler, M. Handley, S. Floyd, J. Padhye, “Datagram Congestion
Control Protocol (DCCP)”, draft-ietf-dccp-spec-13.txt, December
2005.
10.Floyd, S., “Congestion Control Principles”, RFC 2914, September
2000.
11.A. Doria, F. Hellstrand, K. Sundell, T. Worster, “General Switch
Management Protocol (GSMP) V3”, RFC 3292, June 2002.
12.H. Balakrishnan, et al. “The Congestion Manager”, RFC 3124, June
2001.
13.H. Khosravi, S. Lakkavali, “Analysis of protocol design issues for
open standards based programmable routers and switches” [SoftCOM
2004]
14.S. Lakkavali, H. Khosravi, “ForCES protocol design analysis for
protection against DoS attacks” [ICCCN 2004]
15.S. Kent, R. Atkinson, “Security Architecture for the Internet
Protocol”, RFC 2401
11.
Acknowledgments
Appendix A. TML Service Interface
Note that this is just an overview for understanding the protocol
initialization/shutdown sequences. It is by no means complete; the
complete service interface is being specified in a separate draft.
A.1. TML Initialize
status tmlInit(
in channelType,
in initAttributes)
Input Parameters:
Khosravi, et al Expires January 2007 [Page 19]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
channelType: control versus data channel
initAttributes: initialization parameters
Output Parameters:
none
Returns:
status: SUCCESS
Errors TBD
Synopsis:
tmlInit() enables establishment of communication channels on the
entity that this API is invoked. Optionally specifies attributes if
any, for initialization. This call does not however result in the
setup of any channels.
ForCES Usage Model:
In the case of ForCES which follows a client-server model, this API
would be invoked on the CE, which functions as the server. It is
invoked once for every class of TML channels on a per channel type
basis (control channel versus data channel). For example, say for
control messaging, the CE communicates with five FEs using TCP TML
and with another two FEs, using UDP TML. tmlInit() will need to be
invoked twice, once for the TCP TML attributes and once for the UDP
TML attributes for the control channel setup with all of the FEs.
The same holds true for the data channel setup in the above case.
A.2. TML Channel Open
status tmlOpen(
in elementId,
in channelMode,
in ctrlChannelAttributes,
in dataChannelAttributes,
in eventHandlerCallBack)
Input Parameters:
elementId: Specific CE for which channel needs to be setup
channelMode: unicast versus multicast
ctrlChannelAttributes: control channel establishment parameters
dataChannelAttributes: data channel establishment parameters
eventHandlerCallback: Callback function to be invoked on event
generation
Output Parameters:
none
Khosravi, et al Expires January 2007 [Page 20]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
Returns:
status: SUCCESS
Errors TBD
Synopsis:
tmlOpen() results in one or more communication channels for control
and data messaging being established with the specified elementId.
It is up to the TML layer implementation whether to setup a single
channel for both control and data messaging or distinct channels for
each. The channel may be specified as unicast or multicast via
channelMode. This call may either trigger the establishment of the
channel(s), or if the channel(s) are already established, it only
results in a registration for the channel(s). In either case, if
successful, status is returned to indicate successful
creation/registration of the control and data channels. No
descriptors are returned to the PL layer since the TML layer
maintains the mapping between the PL provided elementId and the
descriptors it allocates. If this call triggers the establishment of
the control and data channels, the channels are established using
the ctrlChannelAttributes and dataChannelAttributes parameters
respectively, specified to the call. Once the channel(s) are setup
(or if already setup prior to this call), the caller of this API is
also capable of receiving TML events via the specified event
handling callback function. If this call is invoked multiple times
on a channel that has already been opened and registered, a return
status of ALREADY_REGISTERED is returned, with no change to
registration.
ForCES Usage Model:
In the case of ForCES which follows a client-server model, this API
would be invoked on the FE by FE PL, which functions as the client.
On each FE, it is invoked once for both control and data channels
that the FE wishes to setup with the CE.
Notes:
In the case of TCP TML for the control channel, since there is no
inherent support for multicast, regardless of the channelMode
specified, the specified channel would be setup as a unicast
channel; however, the unicast channel would be able to support
pseudo multicast. Hence, TCP TML has no need to set up distinct
channels for unicast and multicast communication; they are both
mapped to the same TCP connection.
In the case of DCCP TML for the data channel, multicast mode is not
being supported. Hence, channelMode would be ignored.
A.3. TML Channel Close
Khosravi, et al Expires January 2007 [Page 21]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
status tmlClose(
in elementId,
in mode)
Input Parameters:
elementId: address of element with which communication channel is
to be terminated
mode: mode of operation for the close – forced versus controlled
Output Parameters:
none
Returns:
status: SUCCESS
Errors TBD
Synopsis:
Tears down/terminates communication channels connecting to the
specified elementId. This API closes both control and data channels
(regardless of whether they are implemented as a single channel or
distinct channels in the TML layer); it is not possible to close
just one of them. No further CE PL – FE PL messaging is possible
after this. If the mode is specified as controlled, current
messages that are pending in the TML layer shall be sent, but no new
messages shall be accepted by the TML layer on this channel. In the
forced mode, messages pending in the TML layer shall be discarded.
Since the channel was terminated, a subsequent tmlOpen() will
trigger establishment of the channel.
ForCES Usage Model:
This API may be invoked by either the CE or the FE. If the FE PL
invokes it, it specifies a CE ID for the elementId. If the CE PL
invokes it, it specifies an FE ID for the elementId.
A.4. TML Channel Write
status tmlWrite(
in elementId,
in msgType,
in msg,
in msgSize,
in timeout,
out bytesWritten)
Input Parameters:
elementId: address of element to be written to; may be a unicast,
multicast or broadcast address
Khosravi, et al Expires January 2007 [Page 22]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
msgType: control versus data message
msg: message to be sent
msgSize: size of message to be sent
timeout: specifies blocking or non-blocking write. Value of -1
implies blocking write (wait forever), value of 0 implies non-
blocking write
Output Parameters:
bytesWritten: number of bytes actually transmitted
Returns:
status: SUCCESS
Errors TBD
Synopsis:
Sends message to the address specified by elementId. If the
specified elementId is associated with a multicast group, the
message will be sent to all members of the group. Similarly, if the
elementId specified is a broadcast address, the message is sent to
all elements associated with the broadcast address. The msgType
parameter is used to specify whether the message is a control or
data type of message. Based on the message type, the TML will send
the message over the appropriate channel. The TML layer uses the
address specified by elementId and the msgType to map to the
appropriate channel to be used for sending the message. The message
is queued in the appropriate queue for transmission. Once this call
returns, the message buffer may be freed. If TML’s message queues
are full, the timeout will be used to determine how long to wait
prior to returning; if the specified timeout expires, and no message
buffer becomes available, the API returns with an error.
ForCES Usage Model:
This API may be invoked by either the FE PL or the CE PL. If the FE
PL invokes it, it specifies a CE ID for the elementId. If the CE PL
invokes it, it specifies an (unicast/multicast/broadcast) FE ID for
the elementId.
In the case of TCP TML since there is a single channel used for
unicast, multicast and broadcast messaging, the same channel is used
for sending messages regardless of the address specified. In other
cases where there are distinct channels for unicast versus
multicast, the channel to be written to will differ based on the
address specified.
A.5. TML Channel Read
status tmlRead(
in elementId,
Khosravi, et al Expires January 2007 [Page 23]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
in msgType,
in msgBuf,
in timeout,
out bytesRead)
Input Parameters:
elementId: address of element to be read from; may be a unicast,
multicast or broadcast address
msgType: control versus data message
msgBuf: buffer into which message is to be read
timeout: specifies blocking or non-blocking read. Value of -1
implies blocking read (wait forever), value of 0 implies non-
blocking read
Output Parameters:
bytesRead: number of bytes actually read
Returns:
status: SUCCESS
Errors TBD
Synopsis:
Reads message from the specified address. The msgType parameter is
used to specify whether the message to be read is a control or data
type of message. The TML layer uses the address specified by
elementId and the msgType to map to the appropriate channel to be
used for reading the message. Once the message is copied into
msgBuf specified by the call, the TML message buffer may be freed.
If TML’s message queues are empty (no message is available), the
timeout will be used to determine how long to wait prior to
returning; if the specified timeout expires, and no message becomes
available, the API returns with an error.
If a non-blocking read is executed, the caller of the API is
notified via an upcall when a message becomes available.
ForCES Usage Model:
This API may be invoked by either the CE or the FE. If the FE PL
invokes it, it specifies a CE ID for the elementId. If the CE PL
invokes it, it specifies an (unicast/multicast/broadcast) FE ID for
the elementId.
In the case of TCP TML since there is a single channel used for
unicast, multicast and broadcast messaging, the same channel is used
for reading messages regardless of the address specified. In other
cases where there are distinct channels for unicast versus
multicast, the channel to be read from will differ based on the
address specified.
Khosravi, et al Expires January 2007 [Page 24]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
A.6. TML Multicast Group Join
status tmlMulticastGroupJoin(
in groupId,
in groupAttributes)
Input Parameters:
groupId: address of multicast group to join
groupAttributes: attributes associated with the multicast group to
be joined
Output Parameters:
none
Returns:
status: SUCCESS
Errors TBD
Synopsis:
Joins the multicast group specified by groupId as leaf node in the
group. Once a member of this group, the entity calling this API will
be capable of receiving messages addressed to this multicast group.
The TML layer on each end (CE/FE) maintains the mapping between the
PL layer multicast address and the descriptors. The TML layer on
the element which is the root of the multicast updates the set of
elements that are members of the group specified by groupId.
ForCES Usage Model:
This API would be invoked on both the CE and the FE. Initially, the
intent is to only support FE multicast. In such a case. on the FE
the API is invoked once the PL layer on the FE receives a request
from the PL layer on the CE to join a specified multicast group. On
the CE it is invoked after the FE has successfully joined the
multicast group.
A.7. TML Multicast Group Leave
status tmlMulticastGroupLeave(
in groupId)
Input Parameters:
groupId: address of multicast group to leave
Output Parameters:
none
Returns:
Khosravi, et al Expires January 2007 [Page 25]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
status: SUCCESS
Errors TBD
Synopsis:
Leaves the multicast group specified by groupId it had previously
joined. Once an entity is not a member of the multicast group, it is
no longer capable of receiving messages addressed to group. The
TML layer on each end (CE/FE) updates the mapping between the PL
layer multicast address and the descriptors. The TML layer on the
element which is the root of the multicast updates the set of
elements that are members of the group specified by groupId.
ForCES Usage Model:
This API would be invoked on both the CE and the FE. Initially, the
intent is to only support FE multicast. In such a case, on the FE
the API is invoked once the PL layer on the FE receives a request
from the PL layer on the CE to leave a specified multicast group. On
the CE it is invoked after the FE has successfully left the
multicast group.
Authors' Addresses
Hormuzd Khosravi
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: 1-503-264-0334
Email: hormuzd.m.khosravi@intel.com
Furquan Ansari
101 Crawfords Corner Road
Holmdel, NJ 07733
USA
Phone: +1 732-949-5249
Email: furquan@lucent.com
Jon Maloy
Ericsson Research Canada
8400 Boul Decarie
Ville Mont-Royal, Quebec H4P 2N2
Canada
Phone: 1-514-345-7900
Email: jon.maloy@ericsson.com
Shuchi Chawla
Intel
Khosravi, et al Expires January 2007 [Page 26]
Internet Draft TCP/IP based TML for ForCES protocol July 2006
2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: 1-503-712-4539
Email: shuchi.chawla@intel.com
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Khosravi, et al Expires January 2007 [Page 27]
