1
TCP/IP based TML (Transport Mapping Layer) for ForCES Protocol
Hormuzd KhosraviShuchi ChawlaFurquan AnsariJon Maloy
62nd IETF Meeting, Minneapolis
2
Topics
TCP/IP TML Overview CE-FE Communication Channels Unicast and Multicast Messaging TML Messaging TML Service Interface TML Service Interface Usage
– Channel Setup– Multicast Support
Opens Summary
3
TCP/IP TML Overview
Reliability: TCP/IP as transport provides reliability
Congestion Control: TCP/IP as transport provides congestion control
Security: Use of TLS provides desired security
Addressing: – Unicast: standard use of TCP/IP channels– Multicast: simulated over unicast channels
4
TCP/IP TML Overview (contd.)
Prioritization: – Scheduling within TML over a channel– Use of separate data and control channels
Encapsulations: Propose use of a TML header for PL messages and messages it generates [requirement for a TML header under investigation]
High Availability: – TML Heartbeats [under investigation, may not be
required if PL heartbeat exists]– Channels setup between active and standby CEs to an
FE Protection (Mitigation) Against DoS Attacks:
– Separation of data and control messaging via use of separate channels
– Prioritization of control messages
5
CE-FE Communication Channels
CE TML (Server)
FE TML (Client)
TCP Control Channel (Cc)
TCP Data Channel (Cd)
FE PL
FE TML(Client)
FE PL
FE TML(Client)
FE PL
CE PL
TCP Control ChannelTCP Data Channel
FE1 FE2FEN
6
CE-FE Communication Channels (contd.)
Separate control and data channels CE listens for channel setup by FE on well-
defined (server) port Channel setup initiated by FE (client) Channel shutdown may be initiated by
either CE or FE Control and data channels between each
CE (active/standby) and each FE Prioritization of messages over the
channels
7
Unicast and Multicast Messaging Unicast and multicast messaging supported over
unicast communication channels
Simulated Multicast Support:– Multicast join/leave messages sent over control channel
[under investigation: model may change from receiver initiated to CE configured]
– Using multiple unicast channels
Mimic behavior of Traditional Multicast:– Multicast group information obtained through
configuration– Receiver initiated multicast tree setup [under
investigation: model may change from receiver initiated to CE configured]
– CE: root/source of multicast tree– FE: leaf/receiver of multicast tree
8
Unicast and Multicast Messaging
Unicast versus multicast message distinguished via the channel/group descriptor used when sending message
9
TML Messaging TML transports:
– PL control messages– PL data messages– TML control messages [under investigation if any control messages
are required – may be transported over a separate TML control channel]
Minimal/Shim TML Header used for de-multiplexing messages [under investigation if TML header is required]
– Flag: Protocol flag for de-muxing PL/TML messages– Version: TML Version– Message Type: Different TML Messages (e.g. Join/Leave)– Message length: Length of TML message only (not of entire
payload)
Version Flag Message Type LengthMessage Body
10
TML Service Interface
Provides a service interface to an upper layer protocol (PL)
Support for:– Channel setup and shutdown– Multicast group join and leave– Write/send message (unicast or multicast)– Read/receive message
11
TML Service Interface (contd.)
tmlInit: Enable establishment of channels. [CE] tmlOpen: Set up a unicast channel. [FE] tmlClose: Shut down a unicast channel. [CE or
FE] tmlWrite: Send a message over a channel. [CE or
FE] tmlRead: Read a message over a channel. [CE or
FE] tmlMulticastGroupJoin: Join a multicast group.
[FE] tmlMulticastGroupLeave: Leave a multicast group
joined previously. [FE]
12
TML Service Interface Usage: Channel SetupFE PL FE TML CE TML CE PL
tmlInit (Cc)tmlInit (Cd)
tmlOpen(Cc)
TCP ctrl chan (Cc) setup
CcDes
Association, capability, topology info
Setup control channel
Setup data
channel
CE init/ boot up
STEADY STATE OPERATION
tmlEvent (CcUp)CcDes
tmlEvent (CcUp)
tmlOpen(Cd)TCP data chan (Cd) setup
CdDestmlEvent (CdUp)
CdDestmlEvent (CdUp)
tmlWrite (CcDes)tmlRead(CcDes)
13
TML Service Interface Usage: Multicast Support [under investigation]
FE1 PL FE1 TML CE TML CE PL
tmlMcGrpJoinMulticast group joinJoin
multicast group
STEADY STATE OPERATION
Join upcall Grp X = {FE1}Join ok
tmlWrite (X)Write to
McGrp X msg sent to
FE1 only
FE2 PL FE2 TML CE TML CE PL
tmlMcGrpJoinMulticast group joinJoin
multicast group
Join upcall Grp X = {FE1, FE2}Join ok
tmlWrite (X)Write to
McGrp X msg sent to
FE1 and FE2
1st join req. for McGrp. Create grp.
2nd join req. for McGrp X. Update grp. members
14
TML Service Interface Usage: Multicast Support (contd.) [under investigation]
FE2 PL FE2 TML CE TML CE PL
tmlMcGrpLeaveMulticast group leaveLeave
multicast group
STEADY STATE OPERATION
Leave upcall Grp X = {FE1}Leave ok
tmlWrite (X)Write to
McGrp X msg sent to
FE1 only
Update grp. members
15
Opens/Under investigation
Broadcast messaging model Detailed High Availability model Details on message prioritization TML Messaging/Encapsulations: Are TML
control messages required? Multicast Model: Receiver initiated versus
CE configured
16
Summary
TCP/IP based TML for ForCES protocol:– TCP/IP is widely deployed and meets TML requirements
Provides a Service Interface for PL Areas missing in previous draft that have been
addressed in this version:– Connection setup– Uni/Multicast support– TML messaging/encapsulations– Service Interface
Request: “TCP/IP based TML for ForCES Protocol” be made a Working Group draft
17
Backup
18
Problem Statement
Requirements RFC 3654 – “Protection against Denial of
Service Attacks (based on CPU overload or queue overflow) - Systems utilizing the ForCES protocol can be attacked using denial of service attacks based on CPU overload or queue overflow. The ForCES protocol could be exploited by such attacks to cause the CE to become unable to control the FE or appropriately communicate with other routers and systems. The ForCES protocol MUST therefore provide mechanisms for controlling FE capabilities that can be used to protect against such attacks. FE capabilities that MUST be manipulated via ForCES include the ability to install classifiers and filters to detect and drop attack packets, as well as to be able to install rate limiters that limit the rate of packets which appear to be valid but may be part of an attack (e.g., bogus BGP packets).”
19
Possible Solutions
Basic Idea – Separation of data and control messages
– Data messages are control protocol packets such as RIP, OSPF, BGP packets. All other messages considered control messages
Solution 1 – Different Transport connections– Use different congestion aware transport protocol
connections for data and control messages
Solution 2 – Different Prioritization– Assign higher priority to control messages and use
scheduling mechanisms in protocol to differentiate
20
Experimental Setup
Used IXIA box as packet generator and Linux PCs as CE, FE connected using 100 Mbps Ethernet links
Basic implementation consisting of multi-threaded client/server on Linux using pthreads (RR scheduling for threads)
Increased data connection rate to simulate DoS Attack
Linux PC (ControlElement)
Linux PC (ForwardingElement)
Controlconnection(10 Mbps)
Dataconnection
(10-100 Mbps)IXIA (packetgenerator)
Ethernet
Ethernet
Ethernet
21
Experimental Results
Using TCP for control and UDP for data messages (with and without prioritization for control)
Results show UDP (data) overwhelms TCP (control) traffic during DoS attack, prioritization of No help
0
0.2
0.4
0.6
0.8
1
1.2
0 50 100 150
Redirection Data Rate (Mbps)
Rece
ived
/Sen
t Dat
a (lo
ss) Control
Data
Data w/oControl
0
0.2
0.4
0.6
0.8
1
1.2
0 50 100 150
Redirection Data Rate (Mbps)
Rece
ived
/Sen
t Dat
a (lo
ss)
Control
Data
With Prioritization
22
Experimental Results (contd..)
Using TCP for control and TCP for data messages (with and without prioritization for control
Results show control traffic is not overwhelmed by data traffic during DoS attack, prioritization helps improve the performance (by 5%)
0
0.2
0.4
0.6
0.8
1
1.2
0 50 100 150
Redirection Data Rate (Mbps)
Rec
eive
d/S
ent D
ata
(loss
)
Control
Data
0
0.2
0.4
0.6
0.8
1
1.2
0 50 100 150
Redirection Data Rate (Mbps)
Rec
eive
d/S
ent D
ata
(loss
)
Control
Data
With Prioritization
23
Protocol for Data Channel
May need further investigation Other options:
– Datagram Congestion Control Protocol (DCCP)– Provides congestion control but not reliable (which
satisfies requirements for data channel)– Experimented with this but no stable implementation
available at this point
– Generic Routing Encapsulation (GRE) Tunneling
– Encapsulate data packets in a GRE header data channel is a GRE tunnel
– Rate limiting may be done by the FE to provide support for congestion control
– Consider other tunneling protocols