1. by Alex Audu, Jamal H. Salim, Avri Doria Forces-IPTML Design

2. NOKIA RESEARCH CENTER / BOSTON ForCES FRAMEWORK CE ForcesPL TML ForcesPL Silicon API FE Internal Control External Control Data Wire

3. NOKIA RESEARCH CENTER / BOSTON TML Functions  Reliable Service to FPL  Used to transport internal control messages between CE and FE  Unreliable Service to FPL  Used to transport externally sourced control data (e.g. Hello packets) between CE and FE  Security  Authenticate FE endpoints  Authenticate messages.  Congestion Control  Unicast, Multicast and Broadcast  Stream Prioritization

4. NOKIA RESEARCH CENTER / BOSTON Key Design Criteria  Simplicity  Easy to implement  Keep generic functions in PL layer  Statelessness  Stateless as much as possible to reduce complexity  Transparent as much as possible to CE-PL and FE-PL  Security and Anti-DOS  Provide independent data and control paths between PLs  One may be in reliable and the other in unreliable mode  Trust Model  CE-TML is the trusted node.  FE-TML has to authenticate to CE-TML

5. NOKIA RESEARCH CENTER / BOSTON TML Overview  ULP to TML Interface  Calls out minimum service primitives TML has to provide ULP to achieve peer-to-peer ULP communication.  Primitives map to implementation specific APIs.  TML to TML Messages  Specify message interaction between peer TMLs to provide needed services to ULPs.  Message consists of common header and a payload.

6. NOKIA RESEARCH CENTER / BOSTON ULP-to-TML Interface  Initialize – allows ULP to initialize TML layer  Join – allows FE-ULP to join a CE-TML unicast group.  Join Multicast – allows FE endpoint to join a multi-cast address group in CE-TML  Leave – allows FE-ULP to leave a CE-TML unicast group  Leave Multicast – allows an end-point to leave a multicast address group.  Shutdown – allows ULP to shut down TML gracefully  Send-Reliable – allows ULP to send data reliably to peer  Send-Unreliable – allows ULP to send data unreliably to peer.  Receive – allows ULP to get (poll) data from TML  Data-Arrive – allows TML to inform ULP of data arrival (asynch)  Link-Error – allows TML to inform ULP of various link errors  Status – allows ULP to poll TML of TML operational status

7. NOKIA RESEARCH CENTER / BOSTON TML-to-TML Messages  Message Classes: Messages classified into 6 groups –  Management Messages (TM) For initializing, shutdown and monitoring status  Connection Association (CA) Establish logical connection between CE-TML and FE-TML  Security Association (SA) For endpoint (FE-TML) authentication  Boundary Primitive Transport (BP) Transport peer-to-peer ULP messages opaquely via TML  Asynchronous Event Handling (EH) Report asynchronous events to ULP  Vendor Specific Extensions (VSE) Help extend protocol beyond its current limits.

8. NOKIA RESEARCH CENTER / BOSTON Forces-IPTML Message Structure verseTypeprioreservedmsgClassmsgType Message length Source-Address Sequence Number Message body ( Payload) 4811 16 024 31 Destination Address

9. NOKIA RESEARCH CENTER / BOSTON Message Class and Messages  Connection Association  Join/Leave (request and response – unicast)  Join-MCast/Leave-MCast (request and response – multicast)  Security Association  Authenticate (request and response).  Boundary Primitives Transport  Data-Reliable/Unreliable (Request and Response).  Asynchronous Events  Error-Report, Alarm-Report, Notify  Management  Initialize, Shutdown (Request/Response), Status (request/response), Heartbeat (request/response)  Vendor Specific Extension  VS-Data (request/response)

10. NOKIA RESEARCH CENTER / BOSTON Questions

11. Backup

12. Layers and Interfaces CE ForcesPL TML ForcesPL Silicon API FE Internal Control External Control Data Wire

13. NOKIA RESEARCH CENTER / BOSTON Layers  TML  Adapts ForCES-PL to non-IP transports (i.e. IP other)  If transport is IP, we shouldn’t need TML.  Very thin layer (doesn’t do authentication or any such thing)  Makes connections with as much transparency as possible  Stateless, unless when providing reliability over un-reliable transport.  Silicon API in FE  Well defined interface for ForCES-PL to talk to FE silicon.  Needed to decouple protocol from details of FE silicon  Allows FE silicon and Forces-PL to evolve independently.

14. NOKIA RESEARCH CENTER / BOSTON DOS Protection  Separate Control Channels  One for internally generated control data  One for externally sourced control data (e.g. hellos,..)  Created by establishing two Associations, one for each data path.

15. NOKIA RESEARCH CENTER / BOSTON Backup 2

16. NOKIA RESEARCH CENTER / BOSTON FECE Join Request Join Response Capability Request Capability Response Topology Request Topology Response PE UP PE UP ack PE (FE) ACTIVE PE ACTIVE ack Association Phase Validation of FE endpoint FE Block addressing, handles and relationship State Maintenance (Element State) 1 2 3 4 5 6 7 8 9 10 Data Channel Estab 11

17. NOKIA RESEARCH CENTER / BOSTON FECE Heart beat request Heart beat response Query Request Query Response Port Event Notification Configure Logical Comps Req Normal Operation Control packet redirect 1 2 3 4 5 6 7 8 Configure Logical Comps Ack