by alex audu forces-pl design criteria. nokia research center / boston ne (network element) with...

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.

NE1STDBY

NE2ACTIVE

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


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


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


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 InterfacesCE

ForcesPLTML

TML

ForcesPLSilicon 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 CEJoin Request

Join Response

Capability RequestCapability Response

Topology RequestTopology Response

PE UPPE UP ack

PE (FE) ACTIVEPE ACTIVE ack

Association PhaseAssociation Phase

Validation of FE endpoint

FE Block addressing, handles and relationship

State Maintenance

(Element State)

123456789

10Data Channel Estab11


FE CEHeart beat request

Heart beat response

Query RequestQuery Response

Port Event Notification

Configure Logical Comps Req

Normal OperationNormal Operation

Control packet redirect

12345

678

Configure Logical Comps Ack

by alex audu forces-pl design criteria. nokia research center / boston ne (network element) with...

Documents