1 / 34

Stitching Framework GN3-JRA2-T2

Stitching Framework GN3-JRA2-T2. OGF28, March 16 th 2010, Munich Victor 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.

tolinka-gomez
Télécharger la présentation

Stitching Framework GN3-JRA2-T2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Stitching FrameworkGN3-JRA2-T2 OGF28, March 16th 2010, MunichVictor Reijsvictor.reijs@heanet.ie

  2. Outline • Main aspect of Stitching Framework… • DOMAIN and PATH object… • PARAMETER object… • A PATH from A to B… • Demonstration… • Time for questions…

  3. The known drawing board

  4. 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…

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

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

  7. Linking Domain IP Termi-nation domain Termi-nation domain Ether DOMAIN and PATH object (3/3) Linking Domain IP Ether Ether Ether egress ingress egress ingress Path

  8. 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?)

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

  10. 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)

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

  12. PARAMETER examples IP Ether Phys Perf SLS ID

  13. Small list of PARAMETERs

  14. Possible other PARAMETERs

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

  16. 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!

  17. IP User A IP User B A PATH from A to B Ether Domain OOO Domain Path

  18. 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-scheduledPATH (using certain decision criteria)

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

  20. Demonstration • Generic workflow… • Prototype demonstration…

  21. PATH list

  22. Initialize Stitching Engine

  23. 1st: LogicalInterface check

  24. Black PATH

  25. MPLS Domain7 ID ID ID IP IP MPLS Domain1 Domain3 MPLS Ether Ether Ether Ether Phys Phys Phys Phys Perf SLS SLS Black PATH

  26. Green PATH

  27. OOO Domain6 Ether Domain4 ID ID ID ID IP IP Domain1 Domain3 Ether Ether Ether Ether Phys Phys Phys Phys Phys Phys Perf Perf SLS SLS Green PATH

  28. 2nd: All PARAMETER check

  29. Ask and receive PARAMETERs

  30. OOO Domain6 Ether Domain4 ID ID ID ID IP IP Domain1 Domain3 Ether Ether Ether Ether Phys Phys Phys Phys Phys Phys Perf Perf SLS SLS Green PATH IP IPAddress IPSubnetMask AutoIP Ethernet VLANID VLANTagging Physical InterfaceSpeed InterfaceWaveLength AutoNegotiations

  31. Check if solution possible

  32. Prototype demonstration • Check LogicalInterfaces black PATH… • Check LogicalInterfacesgreenPATH… • Check all PARAMETERs greenPATH… • Domain for domain

  33. Interconnectivity

  34. Time for questions Thank you! http://www.geant2.net/upload/pdf/GN2-07-066v5-DJ3-5-3-Report_on_Testing_of_Technology_Stitching.pdf

More Related