ForCES Working Group Weiming Wang
Internet-Draft Ligang Dong
Expires: Sept., 2006 Bin Zhuge
Zhejiang Gongshang Univ.
Mar. 2006
TCP and UDP based ForCES Protocol TML over IP Networks
draft-wang-forces-iptml-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 [RFC2119].
Abstract
This document defines ForCES Transport Mapping Layer (TML) over IP
networks, the framework and the specifications to meet the ForCES TML
requirements.
Internet Draft ForCES TML over IP Mar. 2006
Table of Contents
1. Introduction....................................................2
2. Definitions.....................................................3
3. ForCES TML Overview.............................................3
3.1. TML in ForCES Framework....................................3
3.2. TML Requirements...........................................5
3.3. PL-TML Service Primitives..................................7
4. IP TML Framework................................................7
4.1. Connection Manager Component (CMC).........................9
4.2. Arbiter Component (AC)....................................10
5. IP TML to meet TML Requirements................................11
5.1. Reliability...............................................11
5.2. Security..................................................12
5.3. Congestion Control and Protection against DoS Attacks.....12
5.4. High Availability.........................................12
5.5. Multicast.................................................13
5.6. Prioritization............................................15
5.7. Encapsulation.............................................16
6. Security Considerations........................................16
7. IANA Considerations............................................17
8. References.....................................................17
9. Author's Address...............................................17
1. Introduction
The Forwarding and Control Element Separation (ForCES), the
requirements have been defined in RFC3654, and the framework in
RFC3746. The ForCES protocol, which standardizes the interface
between Control Element (CE) and Forwarding Element (FE), is being
defined in [ForCES-PL] by IETF.
Variant transport media (like IP, ATM, Ethernet, etc) may be applied
to ForCES protocol for the interconnection between CE and FE. To make
the ForCES protocol specification independent of these variant
transport means, a Transport Mapping Layer (TML) is induced in the
ForCES protocol. It is expected that different TML specifications be
individually defined in IETF. A set of service primitives is being
defined to provide standard interconnection between the ForCES
Protocol Layer(PL) and the TML [TML-SP].
This document defines a TCP and UDP based ForCES Transport Mapping
Layer (TML) over IP networks. It applies TCP and UDP protocols as the
transport protocol for the ForCES protocol messages. Detailed
specifications are presented in this document for this TML to meet
the ForCES TML requirements. The specification also meets the
requirements of PL-TML service primitives defined in [TML-SP]
W. M. Wang Expires Sept., 2006 [Page 2]
Internet Draft ForCES TML over IP Mar. 2006
2. Definitions
Many definitions related to ForCES can be found in RFC3654, RFC3746
and the ForCES protocol [ForCES-PL], like:
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 [ForCES-PL].
ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
ForCES protocol architecture that uses the capabilities of existing
transport protocols to specifically address 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.
The ForCES TML specifications are detailed in separate ForCES
documents, one for each TML.
This document defines the following notions:
ForCES TML over IP networks -- TML for ForCES protocol that are
applied to CE-FE interconnect networks, which run IP protocol at the
Network Layer.
IP TML -- Specifically means ForCES TML over IP networks in this
document, it uses TCP and UDP as the transport protocols.
Connection Manager Component (CMC) -- a component in IP TML that is
responsible for all IP TML level connection management.
Arbiter Component (AC) -- a component in IP TML that is responsible
for putting PL messages into IP TML level connections.
3. ForCES TML Overview
3.1. TML in ForCES Framework
The ForCES protocol[ForCES-PL] has defined the relationship between
ForCE PL and TML in the protocol framework, as shown in Figure 1. CE
and FE form a peer-to-peer structure in the framework, where CE PL
peers to FE PL and CE TML peers to FE TML. A TML always lies below a
PL in the same ForCES NE and provides services to the PL. Interface
between PL and TML is standardized by means of a set of service
primitives[TML-SP].
+-----------------------------------------------
W. M. Wang Expires Sept., 2006 [Page 3]
Internet Draft ForCES TML over IP Mar. 2006
| CE PL layer |
+-----------------------------------------------
| CE TML layer |
+-----------------------------------------------
^
|
ForCES |
PL Messages |
over TML |
|
|
v
+-----------------------------------------------
| FE TML layer |
+-----------------------------------------------
| FE PL layer |
+-----------------------------------------------
Figure 1. The TML in the ForCES Protocol Framework
During ForCES pre-association phase, a CE/FE TML is usually managed
by CE Manager(CEM)/FE Manager(FEM), as shown in Figure 2, so as to be
pre-configured with some initialization parameters, like parameters
of TML connections.
+-----------+ +-----------+
| CEM | | FEM |
+-----------+ +-----------+
^ ^
+-----------|------------+ +-----------|------------+
|CE | | |FE | |
| ... Y | | ... Y |
| +-----------+ | | +-----------+ |
| | TML | | | | TML | |
| +-----------+ | | +-----------+ |
| ^ | | ^ |
+-----------|------------+ +-----------|------------+
+---------------------------------+
Figure 2. TML during ForCES pre-association phase
Note that although Figure 2 shows CEM/FEM being entities outside
CE/FE, it is also possible CEM/FEM are physically embedded in CE/FE.
During ForCES post-association phase, ForCES PL is activated. TML is
then associated to the local PL. From ForCES model point of view, to
associate a CE/FE TML to the CE/FE PL is actually to associate the
CE/FE TML to the CE/FE protocol entities in the CE/FE. In FE, the
protocol entity is the FE protocol LFB. Note that at the same time,
TMLs will have to still be associated to CEM/FEM. (This actually
infers that CEM/FEM will still be active during the post-association
W. M. Wang Expires Sept., 2006 [Page 4]
Internet Draft ForCES TML over IP Mar. 2006
phase). Figure 3 shows the diagram for TML during post-association
phase.
+-----------+ +-----------+
| CEM | | FEM |
+-----------+ +-----------+
^ ^
| |
+------------------------+ | | +------------------------+
|CE | | | |FE |
| ... ... | | | | ... ... |
| | | | | |
| +---------------+ | | | | +---------------+ |
| |CE protocol | | | | | |FE Protocol LFB| |
| |Entity | | | | | | ... | |
| | +-----------+ | | | | | | +-----------+ | |
| | |Entity Core| | | | | | | | LFB Core | | |
| | +-----------+ | | | | | | +-----------+ | |
| | ^ | | | | | | | ^ | | |
| |Service | | | | | | | |Service | | | |
| Primitives| Y | | | | | Primitives| Y | |
| | +-----------+ | | | | | | +-----------+ | |
| | | TML |<------ + +------>| TML | | |
| | +-----------+ | | | | +-----------+ | |
| | ^ | | | | ^ | |
| +-------|-------+ | | +-------|-------+ |
+-----------|------------+ +-----------|------------+
| |
+---------------------------------+
Figure 3. TML during ForCES post-association phase
Figure 3 also indicates that:
1. TML properties (attributes, capabilities, events, etc) appearing
at the PL level are actually part of the properties of CE/FE
Protocol entities.
2. PL-TML Service Primitives are used by cores of CE/FE Protocol
entities to access the TML properties as well as to send/receive
PL messages via TML.
From Figure 3, we also see that, TML receives configurations from
both PL layer and CEM/FEM during the post-association phase. It is
important to recognize the difference of the two types of management.
CEM/FEM management for TML at post-association phase is a consistent
management from pre-association phase, which is mainly for TML
connection management, while PL level management for TML is for the
management that is independent of actual TML medias and only based on
the uniformly defined service primitives.
3.2. TML Requirements
W. M. Wang Expires Sept., 2006 [Page 5]
Internet Draft ForCES TML over IP Mar. 2006
The ForCES protocol[ForCES-PL] has defined the general requirements
to all types of ForCES TMLs, as below:
1. Reliability
As defined by RFC 3654, section 6 #6.
2. Security
TML provides security services to the ForCES PL. TML layer should
support the following security services and describe how they are
achieved.
* Endpoint authentication of FE and CE.
* Message Authentication
* Confidentiality service
3. Congestion Control
The congestion control scheme used needs to be defined. The
congestion control mechanism defined by the TML should prevent the FE
from being overloaded by the CE or the CE from being overwhelmed by
traffic from the FE. Additionally, the circumstances under which
notification is sent to the PL to notify it of congestion must be
defined.
4.Uni/multi/broadcast addressing/delivery if any
If there is any mapping between PL and TML level Uni/Multi/Broadcast
addressing it needs to be defined.
5. HA decisions
It is expected that availability of transport links is the TML's
responsibility. However, on config basis, the PL layer may wish to
participate in link failover schemes and therefore the TML must
support this capability.
6. Encapsulations used.
Different types of TMLs will encapsulate the PL messages on
different types of headers. The TML needs to specify the
encapsulation used.
7. Prioritization
It is expected that the TML will be able to handle up to 8 priority
levels needed by the PL layer and will provide preferential treatment.
TML needs to define how this is achieved. The requirement for
supporting up to 8 priority levels does not mean that the underlying
TML MUST be capable of handling up to 8 priority levels. In such an
event the priority levels should be divided between the available TML
priority levels. For example, if the TML only supports 2 priority
W. M. Wang Expires Sept., 2006 [Page 6]
Internet Draft ForCES TML over IP Mar. 2006
levels, the 0-3 could go in one TML priority level, while 4-7 could
go in the other.
8. Protection against DoS attacks
As described in the Requirements RFC 3654, section 6
3.3. PL-TML Service Primitives
PL-TML service primitives are standard interface between PL and TML
for the information exchanges. Six service primitives are defined, as:
TMLopen()
TMLclose()
TMLconfig()
TMLquery()
TMLsend()
TMLreceive()
The TML service primitives and the TML property definitions are
presented in [TML-SP]
4. IP TML Framework
We define the architectural framework of a TCP and UDP based ForCES
TML over IP networks(IP TML) as in Figure 4. Note that this framework
applies to both CE TML and FE TML over IP networks.
-------------------------------------------------------------------
PL Layer
TMLconfig TMLevent TMLsend TMLrecv TMLconfig
TMLopen
Service TMLclose ^ | ^ |
--- Primitives ----|---------|----------------|---------|--------|--
| | Control | Redirect| |
IP TML Layer | | Messages | Messages| |
| | / \ | |
| | / \ | |
| | V V | |
| | | | | | | |
| | |--| |--| | |
| | |--| |--| | |
| | +--+ +--+ | |
| | | | | |
| | V V | |
| | +-----------------------------+ |
| +----->+<-| Arbiter Component (AC) |<-+
| | ------->+-----------------------------+
| | | / \
V | V . . . . . . . .| |. . . . . . . . .
+----------+ . | | .
Ctrl. from |Connection| . | |TCP-UDP pair .
W. M. Wang Expires Sept., 2006 [Page 7]
Internet Draft ForCES TML over IP Mar. 2006
CEM/FEM ------>|Manager |-->. | |Connection(s) .
|Component |<--. | | .
|(CMC) | . . . . . . . .| |. . . . . . . . .
+----------+ | |
------ Sockets ----------------
| | TCP/UDP Layer
| |
-------------------------------
| | IP Layer
| | and Below
| |
--------------------------------------------------------------------
\ /
Network Interface(s)
Figure 4. Framework of IP TML
IP TML as showed in Figure 4 uses a ”TCP-UDP pair connection?for
interconnection between CE TMLs and FE TMLs. A TCP-UDP pair
connection contains a TCP connection and a UDP connection, which MUST
have the same source and destination IP addresses and port numbers.
We define that IP TML connections should always be established in
the form of TCP-UDP pair connection format, i.e., whenever a TCP
connection is established, a UDP connection with the same source and
destination addresses should also be available for the IP TML.
Note that, a UDP in a TCP-UDP pair is capable of multicast when it
gets support from IP multicast protocols.
The TCP-UDP pair connections are managed by a component
called ”Connection Manager Component (CMC)? The CMC is responsible
to all TML connections for the establishment and release, security of
the connections, HA management (at only the TML connection level).
Usually CMC fulfills these tasks by receiving configuration
information from CE/FE Managers as described in Figure 2 and Figure 3.
CMC also receives configuration information from local PL layer by
the PL running TMLConfigure service primitives.
Section 4.1 describes in details the CMC component.
This IP TML framework also defines that interfaces between PL and
TML should comply with the uniformly defined PL-TML service
primitives [TML-SP].
When PL messages are generated by PL layer, they are sent to TML
layer by the TMLsend service primitives. IP TML receives the PL
messages and put the messages into two separate message queues
according to the types of the PL messages. PL messages with ’Redirect
Message?type are put in a redirect message queue, while all other
W. M. Wang Expires Sept., 2006 [Page 8]
Internet Draft ForCES TML over IP Mar. 2006
messages that are called control messages are put in a control
message queue.
PL messages are then put into TML level connections via a component
called “Arbiter Component (AC)? The AC decides when and to which TML
connections a PL message in the two queues should be injected into.
Usually IP TML uses TCP/UDP socket interfaces to put the messages in
the IP TML connections.
The AC also receives PL messages from peer TML via the TML
connections, and makes them ready for local PL layer to fetch by the
PL using TMLReceive service primitives.
The AC may also generate TML events according to the TML connection
state and notifies local PL layer of the events. The TML events
should comply with the TML event specifications defined in the PL-TML
service primitives [TML-SP].
The AC has to receive configuration information from PL layer via
TMLconfigure service primitive.
The AC will also share information about TML connections with CMC.
The TML Connection Table in the CMC can also be accessed by AC. AC
will then use the table to arbitrate PL messages and to put them in
TML connections.
PL messages are encapsulated to TCP/UDP packets in AC before they
are put in IP TML connections. PL messages are decapsulated in AC
when received and before being output to PL.
Section 4.2 describes in details the AC component.
4.1.Connection Manager Component (CMC)
The Connection Manager Component (CMC) receives configuration
information from CE manager (if it is a CE TML) or FE manager (if a
FE TML), as well as from local PL layer.
There is only one kind of TML connections defined in this IP TML:
TCP-UDP pair connection(s). A recommendation for the assignment of
the TCP-UDP pairs is as below:
1. A base TCP-UDP pair connection between every CE and every FE MUST
be applied.
2. Multiple TCP-UDP pair connections between one same CE and one
same FE MAY be applied for the sake of requirements like
prioritization.
3. PL control messages always use TCP in the TCP-UDP pair
connection(s) for transportaion.
W. M. Wang Expires Sept., 2006 [Page 9]
Internet Draft ForCES TML over IP Mar. 2006
4. PL redirect messages always use UDP in the TCP-UDP pair
connection(s) for transportation.
The following steps are adopted to establish a TCP-UDP pair
connection between a CE and a FE:
1. CMC in a CE acts as a server and waiting for a TCP connection
from FEs
2. CMC in a FE acts as a client, and it should have got information
from the FE manager for connecting to peer CE TML, which usually
include the IP address and the port number for the CE TML.
3. CMC in the FE makes a TCP connection to the CE TML.
4. A UDP connection with the same source and destination addresses
is then simultaneously and implicitly established.
CMC maintains a table called ”TML Connection Table? This table
contains information about all TCP-UDP pair connections that have
been established. For every TCP-UDP pair connection, the table
usually contains the following information:
. Connection destination CE/FE ID
. Connection destination IP address and port number
PL Message type(s) the connection applies for
. PL Message priority(s) the connection applies for
The TML connections establishment process usually happens when TML
receives TMLopen service primitives from local PL. When a new FE is
up and is going to associate itself to a CE, the FE PL usually needs
to open the TML first, then to send a FE Association Message to join.
All active TML connections will be closed and shutdown if a TMLclose
service primitive is received from local PL by a TML. When a FE is
going to leave an CE, it will have to tear itself down first by
sending a FE teardown message to CE, then for the PL to send a
TMLclose primitive to local TML to close all TML connections.
TML connections can be modified or released, some new connections
can be added even after TMLopen service primitive has been executed.
All newly modified connection information will immediately trigger
CMC to change the connection state.
CMC generates TML events and notify local PL of the events by
executing corresponding callback functions, which is logged during PL
subscription of these events. The TML events generated by CMC are:
.TML failure event.
This event will happen when the minimum required TML connections (as
described above) are unavailable.
(More TBD)
4.2.Arbiter Component (AC)
W. M. Wang Expires Sept., 2006 [Page 10]
Internet Draft ForCES TML over IP Mar. 2006
Arbiter Component (AC) should fulfill the following tasks:
1. To decide when and at what a pace to inject PL messages into TML
connections
By AC fulfilling this task, it is expected the IP TML will meet the
TML requirements for prioritization, congestion control, and
protection against DoS attacks from redirect data.
2. To decide which connection(s) a PL message to be injected into.
AC does this work by use of the ”TML Connection Table?generated by
CMC and shared by the AC as described above. AC will use
the ”Destination ID? ”Message type?and ”Message priority? which
are associated with every message received from PL, to match the
table to find out the corresponding IP TML connection(s).
3. To encapsulate PL messages to packets of TML connections or to
decapsulate PL messages from packets of TML connections.
4. To receive PL messages from TML connections and send them to PL
by use of TML service primitives
On receiving packets coming from peer TML, the IP TML just de-
encapsulate them to get PL messages, then to put the messages in a
receive queue waiting for PL to use service primitive to fetch.
5. To generate TML events and to notify local PL of the events by
executing corresponding callback functions if the events have been
subscribed by the PL.
The TML events generated by AC are:
.TML message arrival event
.Redirect message congestion event.
.Control message congestion event
.DoS attack alert event.
5. IP TML to meet TML Requirements
This section defines how ForCES IP TML is specified to meet ForCES
TML requirements.
5.1.Reliability
This IP TML meets the reliability requirement by defining that PL
control messages must be transported by TCP, while PL redirect
messages must be transported by UDP.
W. M. Wang Expires Sept., 2006 [Page 11]
Internet Draft ForCES TML over IP Mar. 2006
TCP reliability features like no packet loss, no reordering, and no
corruption then maps to the reliability of PL control message
transportation, but note that TCP does not grantee a timely
transportation, therefore timeliness should be specifically addressed.
The reason to mandate UDP for PL redirect messages is that:
1. UDP provides relatively raw data transportation performance,
which fits well in the cases where the application level of which
may further be embedded with some Internet protocols like IP, UDP
and even congestion awareness protocols like TCP protocol.
Usually, redirect data may contain data that runs protocols like
TCP, UDP, and IP.
2. UDP provides multicast mechanism. Redirect data generated by CE
may often have to do multicast to many FEs, like some routing
protocols may have to do for their messages.
5.2.Security
(TBD)
5.3.Congestion Control and Protection against DoS Attacks
Although PL control messages and redirect messages are transmitted
separately over TCP and UDP, such separation itself does not provide
congestion control and protection against DoS attacks from redirect
data [GRMP-TEST]. Therefore, IP TML using the framework as Figure 4
may still face the danger of control messages being congested or even
DoS attacked.
This specification does not specify any detailed implementation on
how the IP TML meets the Congestion and DoS attack protection
requirement. This specification also does not require that an IP TML
implementation must provide a pure IP TML layer mechanism for
congestion control and protection against DoS attacks, although
individual implementations may apply such mechanism. Instead, this
specification just defines that an IP TML must provide the following
functions so that PL may use these functions to construct a PL level
congestion control and DoS attack protection. The TML functions
include:
1. DoS attack alert event.
2. Congestion report events, which include control message
congestion event report and redirect message congestion report.
5.4.High Availability
ForCES protocol has provided Heartbeat Messages specifically for
CE/FE availability detection at PL layer, therefore TML layer does
not need to take more care of CE/FE level availability.
W. M. Wang Expires Sept., 2006 [Page 12]
Internet Draft ForCES TML over IP Mar. 2006
TML may take care of High Availability on TML connections.
In this IP TML, every TML connection is a TCP-UDP pair connection. A
TCP connection is connection-oriented and has provided connection
management. Although UDP does not provide such connection management,
the UDP is defined to have to associate to a TCP to form a TCP-UDP
pair. As a Result, IP TML connections that are TCP-UDP pairs usually
do not need to have extra means like heartbeat to detect its
connection availability.
5.5.Multicast
PL level Multicast for ForCES messages must map to IP TML level
multicast by the following rules:
. Multicast control messages from a CE to FEs or from a FE to CEs
must map to multiple unicast TCPs at IP TML
. Multicast redirect messages from a CE to FEs or from a FE to CEs
must map to UDP multicast at IP TML
To fulfill UDP multicast at the IP TML level, a parameter to specify
the IP multicast address to the PL level multicast group must be
assigned. This is defined as a TML attribute, called UDP multicast
list. The purpose of the attribute is to assign an IP multicast
address to a ForCES level multicast group, so that UDP can use this
IP multicast address as its multicast IP address. The attribute
therefore has the following element:
{groupID, IPMcastAdd}
Where, groupID is the PL level multicast groupID, IPMcastAdd is a
multicast IP address.
The attribute can be defined in xml as below:
UDPMcastList
A list mapping IP multicast address to PL level multicast group
groupID
32bits group ID of the PL multicast
uint32
IPMcastAdd
IP multicast address
W. M. Wang Expires Sept., 2006 [Page 13]
Internet Draft ForCES TML over IP Mar. 2006
uint32
UDPMcastList
A list mapping IP multicast address to PL level multicast group
UDPMcastList
IP TML multicast can further be divided into four cases, according
to the multicast message types and the transmission directions, as
below:
1. Multicast control messages from a CE to FEs
2. Multicast control messages from a FE to CEs
3. Multicast redirect messages from a CE to FEs
4. Multicast redirect messages from a FE to CEs
They are described in details as followed.
1. Multicast control messages from a CE to FEs
This is mapped to IP TML by with multiple unicast TCPs, and by the
following steps:
a. CE PL (or its application layer) forms a PL level multicast list.
TML Service Primitive has defined such multicast list as an attribute
of TML [TML-SP]. The attribute includes the following elements:
{FEgroupID, FEmemberID1, FEmemberID2, ...}
Where, FEgroupID is the multicast FE group ID, followed are the FE
members of the multicast.
b. CE PL sends the PL mulitcast list to the CE TML by TMLconfig
service primitives.
c. CE PL also send the PL multicast list to all FE members by use of
ForCES protocol configure messages. The FEs further send the PL
multicast list to the FE TMLs.
d. When a CE PL generates and sends to CE TML a control message
marked with the FEgroupID as its destinations, the CE TML distributes
the messages to individual TCP connections according to the FE member
IDs and the connection information in TML connection tables.
W. M. Wang Expires Sept., 2006 [Page 14]
Internet Draft ForCES TML over IP Mar. 2006
e. At the FEs side, when a CE PL message marked with such FEgroupID
arrives at the FE TML, the FE TML just accepts the message and
delivers it to the FE PL, for the FE TML knows it is a member of the
multicast from the multicast list configured.
2. Multicast control messages from a FE to CEs
(TBD)
3. Multicast redirect messages from a CE to FEs
This multicast is mapped to IP TML with UDP multicast, and by the
following steps:
a. CE PL (or its application layer) forms a PL multicast list and a
UDP multicast list for the PL multicast. The UDP multicast list is
defined as before.
b. CE PL then sends the PL mulitcast list and the UDP multicast list
to the CE TML by TMLconfig service primitives.
c. When the CE TML receives the UDP multicast list, it triggers some
IP layer multicast protocol, like IGMP, to let the CE TML join in the
IP multicast group designated by the IP multicast address in the UDP
multicast list.
d. CE PL also send the PL multicast list and the UDP multicast list
to all FE members by use of ForCES protocol configure messages. The
FE members further send the lists to their TMLs.
e. When an FE TML has received the UDP multicast list, it triggers
some IP layer multicast protocol, like IGMP, to let the FE TML join
in the IP multicast group.
f. When a CE generates and sends to the CE TML a PL redirect message
marked with the multicast group ID as its destinations, the CE TML
transmits the message using UDP protocol and using the IP multicast
address designated by UDP multicast list.
g. At the FEs side, because the TMLs of all FE members have already
joined in the IP multicast group, any of the FE TMLs can receive the
packet transported by the IP multicast address. The PL redirect
message in the packet then be delivered to the FE PL.
4. Multicast redirect messages from a FE to CEs
(TBD)
5.6.Prioritization
W. M. Wang Expires Sept., 2006 [Page 15]
Internet Draft ForCES TML over IP Mar. 2006
This IP TML can meet the different prioritization from PL level by
use of several TCP-UDP pair connections between one same CE and one
same FE.
5.7.Encapsulation
1. TCP Encapsulation
When ForCES PL messages are transported over TCP, a TCP port number
or port numbers (if multiple TCP connections are established) that
are specifically assigned for ForCES protocol should be adopted.
The encapsulation format is as below:
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
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TCP header with the port number for the ForCES protocol ~
| |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ForCES PL Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2. UDP Encapsulation
When ForCES PL messages are transported over UDP protocol, a UDP
port number that is specifically assigned to ForCES protocol should
be used.
The encapsulation format is as below:
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
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ UDP header with the port number for the ForCES protocol ~
| |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ForCES PL Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. Security Considerations
(TBD)
W. M. Wang Expires Sept., 2006 [Page 16]
Internet Draft ForCES TML over IP Mar. 2006
7. IANA Considerations
The Following Assigned Numbers are considered:
TCP Port Number(s) for ForCES Protocol
UDP Port Number for ForCES protocol
8. References
[ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft-
ietf-forces-protocol-02.txt, work-in-progress, Feb. 2005.
[ForCES-Model] Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti,
Z. and S. Blake, "ForCES Forwarding Element Model", October 2003,
http://www.ietf.org/internet-drafts/draft-ietf-forces-model-03.txt.
[TML-SP] W. M. Wang, J. Hadi, ForCES TML Service Primitives, work in
progress, draft-jhs-forces-tmlsp-00.txt.
[GRMP-TEST]L. Dong, L. Shi, and W. Wang, A Testbed for GRMP Protocol,
Proceedings of 59th IETF Meeting, 2004, Feb.29-Mar.4, Seoul, Korea,
http://www.ietf.org/proceedings/04mar/slides/forces-2.pdf
9. Author's Address
Weiming Wang
Zhejiang Gongshang University
149 Jiaogong Road
Hangzhou 310035
P.R.China
Phone: +86-571-88071024
EMail: wmwang@mail.zjgsu.edu.cn
Ligang Dong
Zhejiang Gongshang University
149 Jiaogong Road
Hangzhou 310035
P.R.China
Phone: +86-571-88071024
EMail: donglg@mail.zjgsu.edu.cn
Bin Zhuge
Zhejiang Gongshang University
149 Jiaogong Road
Hangzhou 310035
P.R.China
Phone: +86-571-88071024
EMail: zhugebin@mail.zjgsu.edu.cn
Intellectual Property Statement
W. M. Wang Expires Sept., 2006 [Page 17]
Internet Draft ForCES TML over IP Mar. 2006
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
W. M. Wang Expires Sept., 2006 [Page 18]