1 / 23

by Alex Audu

Forces-PL Design Criteria. by Alex Audu. <draft-audu-forces-pl-00.txt>. NE (Network Element) WITH STATE. Importance of NE State Attribute

fawn
Télécharger la présentation

by Alex Audu

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-PL Design Criteria by Alex Audu <draft-audu-forces-pl-00.txt>

  2. NE (Network Element) WITH STATE • Importance of NE State Attribute • Knowing the reliability and availability of the NE in a deterministic way depends on knowing the state. • Redundancy operation depends on accurate state knowledge. NE with STATE

  3. NE-STATES • NE STATES • OUT-OF-SERVICE (OOS) • IN-SERVICE (ISV) • IN-SERVICE-STANDBY (IN-SERVICE-INACTIVE) • IN-SERVICE-ACTIVE • STATE CHARACTERISTICS • OOS : • NE WON’T CARRY TRAFFIC • NE WILL NOT HONOR TRAFFIC RELATED REQUESTS • WILL HONOR MAINTANANCE RELATED REQUESTS • ISV: • NE CAN CARRY TRAFFIC • NE WILL HONOR TRAFFIC RELATED REQUESTS • NE WILL HONOR MAINTANANCE REALTED REQUESTS

  4. NE STATE TRANSITIONS ACTIVE Command Command Removal INACTIVE OR Failure Command or Failure Command OOS

  5. NE1 STDBY traffic NE2 ACTIVE traffic Use of State Information • Proper operation of redundant NE peer in a network depends on knowledge of NE state. • Because you can have failure induced transitions, it is vital to account for the NE state since this will impact states of the elements in the NE.

  6. STATES INSIDE THE NE • NE Consists of Control and Forwarding elements • ForCES has decoupled Control elements (CE) from Forwarding elements (FE) and interconnected by ForCES protocol. CE CE Forces Protocol FE FE

  7. CE has states: OOS, ISV-STDBY, ISV-ACTIVE FE has states: OOS, ISV-STDBY, ISV-ACTIVE How do these states determine NE state? Element States inside NE

  8. Forces-PL Element States ACTIVE Alternate CE/FE active CE/FE active CE/FE inactive INACTIVE CE/FE down CE-FE communication failure CE/FE down CE-FE communication failure CE/FE UP DOWN

  9. Protocol Overview • ForCES Protocol has to reflect FE states at the CE and CE states at the FE. • ForCES Protocol has to provide both reliable, and unreliable congestion aware links between CE and FE. • Protocol supports communication between CE and FEin a distributed fault-tolerant manner. • Master/Slave relationship between CE-FE. • Protocol messages separated into cohesive groups or messages classes. • Use of Message classes allows for effective management of messages • Use of Message classes allows for effective management of software maintenance/life-cycle management • Uses ACKs and Responses freely to guarantee message delivery and mutual agreement and understanding

  10. Messaging Design (1) • Three possibilities: Fully Coupled API, Fully Decouple API, and Decoupled Cohesive API. • Fully Coupled API (FCA): One generic message API with one Set() and one Get() functions, each with parameters to identify what data is being accessed. • Pros: • Smallest code foot-print in memory. • Cons: • Results in huge “case” or “if” statement • May result in sluggish protocol performance since cycles are wasted navigating a long list of “if” or “case” statements • Not good for code maintenance, since any code change makes testing every legacy functionality necessary during regression testing

  11. Messaging Design (2) • Fully Decoupled API (FDA): Every protocol function has its set() and get() method. • Pros: • fastest and most agile protocol since no time is wasted trying to resolve message target • Best for code maintenance since methods are fully decoupled and changing one or adding a new one doesn’t impact existing code integrity. Thus only need to test added or modified function or feature. • Cons: • Results in lots of message APIs being defined and implemented • Consumes most memory space

  12. Messaging Design (3) • Decoupled Cohesive API (DCA): Functions are decoupled into cohesive groups. This is best of both worlds. Forces-pl uses message classes to group cohesive functions. • Pros: • Best of both worlds • Results in fast protocol operation since “case” or “if” statements are short if they exist, and not many cycles are wasted in navigating them. • Memory usage is optimal • Code maintenance is manage-able: code change impacts are constrained to modified classes, and only features related to those classes need tested when doing regression testing. • Cons: • Less processor cycle time efficient compared to FDA. • Code maintenance is less efficient compared to FDA

  13. Messaging Design (4) • Forces-pl uses ACKs and responses when communicating between peers. • Misunderstanding about ACKs when transport is reliable • Reliable transport guarantees message gets delivered • Need ACKs or responses to ensure peers agree on what needs to be done

  14. Forces-PL Message Structure 31 0 4 8 11 24 16 vers eType prio reserved msgClass msgType Message length Source-Tag Destination-Tag Sequence Number Message body ( Payload)

  15. Message Class and Messages (1) • Association Establishment • To establish logical connection between CE and FE • Join, Leave message etc (multicast and unicast) • Capabilities Exchange & Configuration • To exchange FE’s capabilities and to configure FE’s functions. • Capability request, Configure FE Blocks, Topology request etc • State Maintenance • To track element states and report state changes. • Heart-beat, PE UP, PE Down, PE Active and Inactive etc

  16. Message Class and Messages (2) • Traffic Maintenance • To control data and control traffic between CE and FE. • Packet Redirection, Control packet forwarding etc. • Event Notification • Asynchronous status change notification by FE to CE. • Event Register, Deregister, Notification message,etc.. • Vendor and Application Specific • To extend the protocol beyond its current capabilities. • To exchange application data

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

  18. 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.

  19. 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.

  20. Questions

  21. Backup

  22. 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

  23. 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