stitching framework gn3-jra2-t2

Stitching FrameworkGN3-JRA2-T2

OGF28, March 16th 2010, MunichVictor Reijs

victor.reijs@heanet.ie

Outline

• Main aspect of Stitching Framework…– DOMAIN and PATH object…– PARAMETER object…

• A PATH from A to B…

• Demonstration…

• Time for questions…

The known drawing board

Main aspect of Stitching Framework

• To provide a framework how to interconnect multilayer services in a multi domain environment.

• Looking mainly at interfaces/protocols between peers (on any layer)

• Should support any management tools (incl. humans).

• The framework should be adaptable to new/unknown services

• DOMAIN, PATH and PARAMETER object…

DOMAIN and PATH object (1/3)

• Each domain is seen as autonomous and each domain knows precisely what it can do

• Adaptation&(de)multiplexing are inside a DOMAIN, so not important for stitching, except when information needs to be exchange

• Abstracting the DOMAIN topology, by the Domain itself, is important

DOMAIN and PATH object (2/3)

• Linking domain– Anounces parameters of its two interface sides

(ingress and egrees)– Hides internals; like switching/adaptations/multiplexing

• Termination domain– Anounces parameters of its single interface side (ingress

or egress)• Peering domains

– Two domains that can communicate as soon as interface/protocol parameters are aligned

• A PATH consists of two Termination domains and at least one Linking domain.

DOMAIN and PATH object (3/3)Termi-nation

domain

Linking Domain Linking Domain

IP

Ether EtherEther

Termi-nation

domain

IP

Ether

egress ingress egress

Path

ingress

PARAMETER object

• PARAMETER is entity important for interface/protocol/domain• Technology experts define/document what is important for a

certain service; aka what is essential to align PARAMETERs for a PATH

• PARAMETERs need to be aligned between Peering domains– By using RFCs, Best Practices (for widely used services)– Mutual agreement (for experimental services)

• See a PARAMETER as an object with multiple instances• A PARAMETER has attributes (some at meta level)…

Like Name (IPAddress) and Data (192.168.1.1)• Dependencys between PARAMETERs should be minimized• PARAMETERs can grouped by LogicalInterfaces (Best

Practices?)

PARAMETER attributes (1/3)

• Name– The common name– Unique within Type – Example: IPAddress or GHGUnit

• Data– The real value of the PARAMETER– Example: 192.168.1.1 or 0.01

• Type– Grouping of PARAMETERs; like related to a service– Example: IP or Energy

PARAMETER attributes (2/3)

• Logic determines the scope to align PARAMETERs:– Path (like NOCInformation)– Peering between domain (like InterfaceSpeed)

• Contiguous within domain (like with VLANID)• Noncontiguous within domain (like IPAddress)

• Method how the PARAMETER will be aligned:– Same (VLANID), Different (IPAddress)– Sum (Delay), Overlap (ScheduleUser)

PARAMETER attributes (3/3)

• Intervention how to change the Data value of PARAMETER can be changed:– Auto by protocol (like DHCP for IPAddress)– Remote configuration (like VLANID)– Human intervention (like InterfaceWavelength)

• Other attributes like: Dependency, Dimension.

PARAMETER examplesName Type Intervention Method

IPAddress Auto Different

VLANID Remote Same

Interface speed

Human Same

Bandwidth Remote Minimum

Schedule User

Remote Overlap

NOCInfo Human List

IP

Ether

Perf

Phys

SLS

ID

Small list of PARAMETERs

Possible other PARAMETERs

Other PARAMETER aspects (1/2)

• PARAMETERs should be uni-directional • Attribute values can be single (1), range (1:2)

and/or list (1,2) value• For aligning PARAMETERs it is important to

give as many as possible values• Functions are also possible (sum)• Some attributes values (like for Dimension,

Method) look to be independent of service, but better not to assume such constancy

Other PARAMETER aspects (2/2)

• Using an XML based descriptions sounds logical, like utilizing NSI/NML ideas (when they are finalized).

• SF does not define where and how PARAMETERs are stored

• Perhaps a protocol is needed to allow for dynamic PARAMETER discovery

• Adding new attributes is cumbersome; so give feedback if other attributes are essential!

OOO Domain

A PATH from A to BIP User A Ether Domain IP User B

Path

Stitching process

• A list of possible PATHs is provided by a Pathfinder• It is assumed Pathfinding and Stitching are separate

functions, but they can be combined in PCE.• All domains in the PATH provide their relevant

PARAMETERs.– PARAMETER attribute values can depend on the PATH

(aka ingress and egress domain)

• Stitching Engine (SE) evaluates each path…• SE determines the to-be-scheduled PATH (using

certain decision criteria)

Stitching Engine evaluates

• SE tries to align all gathered PARAMETERs:– SE picks a PARAMETER at the start of a PATH and looks for the next

domain (Peering domain) with the same PARAMETER Name.– SE checks for this PARAMETER is automatically aligned by a protocol

(e.g. DHCP with IP).– If not automatically; SE checks if the Data of the PARAMETERs can be

aligned (keeping Dependancys in mind).– If alternatives for PARAMETER Data are possible, SE decides on the

value and will propose this to Peering domains – SE will do this for all PARAMETERs. If errors (missing peering

PARAMETERs or unable to achieve alignment) error messages will go to Peering domains or all Path domains.

• The SE assumes the domains will schedule the proposed PARAMETER Data (being: manual, remote or auto).

Demonstration

• Generic workflow…

• Prototype demonstration…

PATH list

Initialize Stitching Engine

1st: LogicalInterface check

Black PATH

Black PATHMPLS Domain7

Perf

ID

Ether

Phys Phys

Ether

MPLS MPLS

Domain1

SLS

ID

IP

Ether

Phys

Domain3

SLS

ID

IP

Ether

Phys

Green PATH

OOO Domain6

Perf

ID

Phys Phys

Green PATHDomain1

SLS

ID

IP

Ether

Phys

Ether Domain4

Perf

ID

Ether

Phys Phys

Ether

Domain3

SLS

ID

IP

Ether

Phys

2nd: All PARAMETER check

Ask and receive PARAMETERs

OOO Domain6

Perf

ID

Phys Phys

Green PATHDomain1

SLS

ID

IP

Ether

Phys

Ether Domain4

Perf

ID

Ether

Phys Phys

Ether

Domain3

SLS

ID

IP

Ether

Phys

IPIPAddress

IPSubnetMaskAutoIP

EthernetVLANID

VLANTagging

PhysicalInterfaceSpeed

InterfaceWaveLengthAutoNegotiations

Check if solution possible

Prototype demonstration

• Check LogicalInterfaces black PATH…

• Check LogicalInterfaces green PATH…

• Check all PARAMETERs green PATH…– Domain for domain

Interconnectivity

Time for questions

Thank you!

http://www.geant2.net/upload/pdf/GN2-07-066v5-DJ3-5-3-Report_on_Testing_of_Technology_Stitching.pdf