by Alex Audu

by Alex Audu

<draft-audu-forces-pl-00.txt>

Forces-PL Design CriteriaForces-PL Design Criteria

NOKIA RESEARCH CENTER / BOSTON

NE (Network Element) WITH STATENE (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


NE-STATESNE-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 TRAFFIC2. NE WILL NOT HONOR TRAFFIC RELATED REQUESTS3. WILL HONOR MAINTANANCE RELATED REQUESTS

• ISV:1. NE CAN CARRY TRAFFIC2. NE WILL HONOR TRAFFIC RELATED REQUESTS3. NE WILL HONOR MAINTANANCE REALTED REQUESTS


NE STATE TRANSITIONSNE STATE TRANSITIONS

ACTIVE

INACTIVE

OOS

Removal

OR

Failure

Command Command or Failure

CommandCommand


Use of State InformationUse 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

traffic


STATES INSIDE THE NESTATES 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


Element States inside NEElement 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 oos oos

isv isv isv

isv oos oos (policy)

oos isv isv (policy)

active isv isv

isv active active (policy)

active active active


Forces-PL Element StatesForces-PL Element States

ACTIVE

INACTIVE

DOWN

CE/FE downCE-FE communication failure

CE/FE inactiveCE/FEactive

AlternateCE/FEactive

CE/FE downCE-FE communication failure

CE/FEUP


Protocol OverviewProtocol 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


Messaging Design (1)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


Messaging Design (2)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



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



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


Forces-PL Message StructureForces-PL Message Structure

vers eType prio reserved msgClass msgType

Message length

Source-Tag Destination-Tag

Sequence Number

Message body ( Payload)

4 8 11 160 24 31


Message Class and Messages (1)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


Message Class and Messages (2)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


Layers and InterfacesLayers and Interfaces

CE

ForcesPL

TML

TML

ForcesPL

Silicon API

FE

Internal Control External Control

DataData

WireWire


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


DOS ProtectionDOS 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.


QuestionsQuestions


BackupBackup


FE CE

Join Request

Join Response

Capability Request

Capability Response

Topology Request

Topology Response

PE UP

PE UP ack

PE (FE) ACTIVE

PE ACTIVE ack

Association PhaseAssociation Phase

Validation of FE endpoint

FE Block addressing, handles and relationship

State Maintenance

(Element State)

1

2

3

4

5

6

7

8

9

10Data Channel Estab

11


FE CE

Heart beat request

Heart beat response

Query Request

Query Response

Port Event Notification

Configure Logical Comps Req

Normal OperationNormal Operation

Control packet redirect

1

2

3

4

5

6

7

8

Configure Logical Comps Ack

by Alex Audu

Documents

Transcript of by Alex Audu