TCP/IP based TML (Transport Mapping Layer) for ForCES Protocol

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


Join upcall Grp X = {FE1}Join ok

tmlWrite (X)Write to

McGrp X msg sent to

FE1 only


tmlMcGrpJoinMulticast group joinJoin

multicast group

Join upcall Grp X = {FE1, FE2}Join ok


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]


tmlMcGrpLeaveMulticast group leaveLeave

multicast group


Leave upcall Grp X = {FE1}Leave ok


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


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


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


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

Documents

TCP/IP based TML (Transport Mapping Layer) for ForCES Protocol