1 / 17

by

Forces-IPTML Design. by Alex Audu, Jamal H. Salim, Avri Doria. <draft-audu-forces-iptml-00.txt>. ForCES FRAMEWORK. CE. ForcesPL. TML. Internal Control. External Control. Wire. Data. Wire. Data. TML. ForcesPL.

lavinia-augustus
Download Presentation

by

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Forces-IPTML Design by Alex Audu, Jamal H. Salim, Avri Doria <draft-audu-forces-iptml-00.txt>

  2. ForCES FRAMEWORK CE ForcesPL TML Internal Control External Control Wire Data Wire Data TML ForcesPL Silicon API FE

  3. 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. 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. 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. 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. 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. Forces-IPTML Message Structure 31 0 4 8 11 24 16 vers eType prio reserved msgClass msgType Message length Source-Address Destination Address Sequence Number Message body ( Payload)

  9. 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. Questions

  11. Backup

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

  13. 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. 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. Backup 2

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

  17. Normal Operation FE CE Heart beat request 1 Heart beat response 2 Query Request 3 Query Response 4 Port Event Notification 5 Configure Logical Comps Req 6 Configure Logical Comps Ack 7 Control packet redirect 8

More Related