stitching framework gn3-jra2-t2
Post on 02-Jan-2016
43 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related