ForCES Protocol brain-storming
Some Basic Design Principles
1. The ForCES protocol should be able to take advantage of the features of the
underlying transports (both physical & protocol).
2. The ForCES protocol should explain how and if it runs on physical transports that
are in the following 4 dimensional space, and either ForCES itself or a transport layer
between ForCES and the physical transport provides the additional functionality
needed to meet all ForCES requirements for each space (or it should be explicitly said
"ForCES won't run on this kind of transport"):
Dimension 1: Reliable Delivery <--> Unreliable Delivery
Reliable means: The message will get through, eventually, or sender will get an
indication that it did not, to some very high level of probability
Unreliable means: You send it and have no assurances it made it.
Dimension 2: Correct deliver <--> Corrupt Delivery
Correct delivery means: The message, if it gets through, will get through with no
corruption to some very high level of probability
Corrupt delivery means: Even if the message is delivered, it may have bits corrupted
and you won't know it.
Dimension 3: Unicast <--> Multicast <--> Broadcast
Dimension 4: Congestion control/bandwidth
Guarantees <--> Robust congestion control/BW guarantees
No guarantees means: Your flow could take over the entire communications
channel, unfairly slowing others
Robust means: Your flow will be fair towards others
3. The ForCES protocol should contain within it information that is relevant to all LFBs
and FEs. Examples include LFB naming and identification (e.g. "This message is for
that LFB"), transactioning (e.g. "message A, B, and C must all be done, or do none of
them").
4. The ForCES protocol should mandate a single or minimum set of transport
protocol(s), security protocol(s) for interoperability reasons. It should also explicitly
specify how any optional transport/security protocols are utilized.
5. It should not be necessary to extend the ForCES protocol every time someone defines
a new LFB type. This implies that LFB-specific information should be in a LFBspecific payload carried within the ForCES messages and not fields in the ForCES
header itself.
6. a. The ForCES protocol should support both unicast and multicast addressing for FEs
in the protocol header.
b. The ForCES protocol should hide whether multicast is used or not to the (CE)
users, the FE addressing in the protocol, should allow for logical unicast or multicast.
7. The ForCES protocol should support separate channels for Control and Data
messages. The data channel carries the routing/control protocol packets such as RIP,
OSPF packets, between the CEs and FEs. These packets are unique in most cases for
a particular CE:FE pair and hence the data channel will use unicast connections
between the CEs and FEs. Also, the data channel does not have to be strictly reliable
but does need to provide flow/congestion control to protect against DoS attacks.
8. The control channel must provide strict reliability (non-corruption, no loss, no
reordering, timeliness) at the transport level in accordance with the RFC 3654. In
addition, ForCES protocol level responses/acknowledgements are also needed from
FE to CE to learn the results of configuration/control messages.
Proposed Protocol Features
1. The multicast addressing in the protocol will be based on LFB type basis and not FE
basis, i.e. a multicast group will specific an LFB e.g. IPv4 Forwarding LFB and it will
be used by CE to download the forwarding table entries onto FEs which have that
LFB. However, the LFB ID will need to be specified in the message in case of
multiple instances of same type of LFB.
2. The control channel must consist of unicast connections between the CEs and FEs.
All control messages sent from FE to CE, such as, asynchronous events or
responses/acks, are sent over unicast connections only. There may also be optional
multicast channels between CEs and FEs to carry control information from CE to
multiple FEs.
3. For Local scope –
If the protocol is used directly over Layer 2, then both unicast and multicast can be used
for the control channel (if layer 2 supports multicast). Unicast is mandatory and initially a
unicast connection is formed between the FEs and CE during association establishment
(binding) phase of the protocol. Over this channel, the multicast channels are negotiated
for certain LFB types. Procedures need to be defined in the protocol for negotiation of
multicast channels. Such procedures might include explicit LFB/multicast group
setup/teardown messages in the ForCES protocol itself. Only configuration messages for
LFBs will be sent over multicast channels. For example, a message to configure IPv4
forwarding table could be sent over a multicast group to a bunch of LFBs in different
FEs. All other messages will use unicast connections. Both for unicast and multicast
connections over L2, reliability/flow control mechanisms need to be defined in the
protocol or must be present as properties of the L2 interconnect. For example, the L2
specific encapsulation may define CRC field to check for data corruption. Alternatively,
TIPC could be used to provide reliability mechanisms for the unicast/multicast
connections over Layer 2.
If the protocol is used over IP, then unicast is mandatory and multicast is optional for the
control channel. Unicast connections will use TCP for reliability/flow control. For any
optional Multicast channels, Reliable Multicast Transport (RMT) will to be used to
provide reliability/flow control, etc. The multicast channels will use the same procedures
defined for the Layer 2 case, for initial negotiation. Also, only configuration messages for
LFBs will be sent over multicast channels, as in the case of Layer 2.
The rationale behind this is that certain vendors may have proprietary Layer 2
interconnects between CEs and FEs which support reliable unicast as well as multicast
along with flow control, congestion control, etc. In such cases, it might be most optimal
for vendors to run the ForCES protocol directly over L2 and take advantage of the L2
properties. In case this L2 interconnect is not available, the vendor could choose the run
the protocol over IP and use TCP to provide reliability, flow control, etc. He may also use
standard mechanisms for RMT for optional multicast channels.
4. For Global Scope –
The protocol will run over IP and use unicast TCP connections for the control channel.
Unicast connections will use TCP for reliability/congestion control. It may be possible
for having optional multicast channels, however this is not recommended when using the
protocol in the global scope for reliability, congestion control and security reasons [RFC
3654, section 6 #2, #4, #6].