1. by Alex Audu Forces-PL Design Criteria

2. NOKIA RESEARCH CENTER / BOSTON NE (Network Element) WITH STATE 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. NOKIA RESEARCH CENTER / BOSTON NE-STATES  NE STATES  OUT-OF-SERVICE (OOS)  IN-SERVICE (ISV) IN-SERVICE-STANDBY (IN-SERVICE-INACTIVE) IN-SERVICE-ACTIVE  STATE CHARACTERISTICS  OOS : 1. NE WON’T CARRY TRAFFIC 2. NE WILL NOT HONOR TRAFFIC RELATED REQUESTS 3. WILL HONOR MAINTANANCE RELATED REQUESTS ISV: 1. NE CAN CARRY TRAFFIC 2. NE WILL HONOR TRAFFIC RELATED REQUESTS 3. NE WILL HONOR MAINTANANCE REALTED REQUESTS

4. NOKIA RESEARCH CENTER / BOSTON NE STATE TRANSITIONS ACTIVE INACTIVE OOS Removal OR Failure Command Command or Failure Command

5. NOKIA RESEARCH CENTER / BOSTON 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. NE1 STDBY NE2 ACTIVE traffic

6. NOKIA RESEARCH CENTER / BOSTON 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 FE CE FE Forces Protocol

7. NOKIA RESEARCH CENTER / BOSTON Element States inside NE  CE has states:  OOS, ISV-STDBY, ISV-ACTIVE  FE has states:  OOS, ISV-STDBY, ISV-ACTIVE  How do these states determine NE state? CE State FE State NE State oos isv oos oos (policy) oos isv isv (policy) active isv activeactive (policy) active

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

9. NOKIA RESEARCH CENTER / BOSTON 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 FE in 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. NOKIA RESEARCH CENTER / BOSTON 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. NOKIA RESEARCH CENTER / BOSTON 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. NOKIA RESEARCH CENTER / BOSTON 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. NOKIA RESEARCH CENTER / BOSTON 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. NOKIA RESEARCH CENTER / BOSTON Forces-PL Message Structure verseTypeprioreservedmsgClassmsgType Message length Source-TagDestination-Tag Sequence Number Message body ( Payload) 4811 16 024 31

15. NOKIA RESEARCH CENTER / BOSTON 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. NOKIA RESEARCH CENTER / BOSTON 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. NOKIA RESEARCH CENTER / BOSTON Layers and Interfaces CE ForcesPL TML ForcesPL Silicon API FE Internal Control External Control Data Wire

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

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

20. NOKIA RESEARCH CENTER / BOSTON Questions

21. Backup

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

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