domains and the Stitching Framework (SF) version 2
Hello all of you, A few changes to the pdf file (learnt some more UML). I also added the IDC domain names in the below text. So I am looking at the classes of domains which might be important when working on Stitching (which is trying to connect different domains together by checking if they are or can be made compatible). This work has been done as part of AutoBAHN (GN2 JRA3 activity). The document that describes this Stitching Framework (SF) is here: http://www.geant2.net/upload/pdf/GN2-07-066v5-DJ3-5-3-Report_on_Testing_of_T... This is already an 'old' document (1 year) and was also presented at GLIF in Japan (2006): http://www.glif.is/meetings/2006/controlplane/reijs-jra3.pdf <remember this is all before I knew UML, so it is not using that right UML terminology!> I talked with Freek and we discussed the domains that could be important for NML and I proposed to make an overview of the 'domains' (classes and objects in UML language) which are handy (but not always essential!) in the SF. The SF is just one view of reality (a use case), so there might be less classes (more objects) or more classes (less objects) when looking at all use cases of domains. At least the ones I discuss were in some way handy when talking about stitching (the ones with a * at the end look to be important for path finding and stitching). The below list comes from the above GEANT2 document (section 2.2.1) and I tried to UML-ize it (but I am really a novice on UML!). <I am still not 100% confident when to use classes, objects, attributes or values in UML, I am working on that> I tried to check the terminology used within AutoBAHN and IDC (but I did was not able to fully cover this). It also is written from the view of Bandwidth on Demand (circuits), but it can just as well work in packet switched networks, application environment and/or political levels;-) So anywhere compatibility is needed.. Remember I might use IDC and AutoBAHN as examples, but they might not have implemented it!!! I also did not check it with NMWG doc. 'Hierarchy of Characteristics', which is I assume: http://www-didc.lbl.gov/NMWG/docs/draft-ggf-nmwg-hierarchy-02.pdf ? The domain classes that play a some role in the use case, which uses the SF, are : • Termination domain This domain is where the possible path begins or ends. At least two Termination domains must exist in each path. A Termination domain can be a single workstation or a full-blown network (with demand for multiple paths). The Termination domain is not managed by the service (like AutoBAHN/IDC). It has only one 'side' (egress at start of the path and ingress at end of the path). • User domain* [AutoBAHN: UserAccessPoint?] [IDC: End-User] A User domain is a kind of the Termination domain and it is where the actual User’s system/network resides. • Linking domain* [AutoBAHN: External?] A Linking domain has known interfaces/protocols/processes and is one of the domains that make up the possible path between two Termination domains. If a proposed path (LIDP: Loose Inter-Domain Path) is possible all Linking domains together will form the actual path (SIDP: Strict Inter-Domain Path) (like AutoBAHN or IDC). A linking domain has two 'sides' (ingress and egress) • Home domain The Home domain is the domain that will accept the BoD request from a User. The Home domain does not have to be an actual Linking domain in the path; the Home domain is just the domain where the User sends his/her BoD request. So the Home domain acts as a proxy to the service and determines the Source Domain). • Source domain* [AutoBAHN: HomeDomain?] [IDC: Source/Endpoint] This is the first Linking domain that is part of the possible path. It might starts the investigation if a the BoD request can be made. • Destination domain* [AutoBAHN: LastDomain?] [IDC: Destination/Endpoint] This is the last Linking domain that is part of the possible path. It might do the path finding and feasibility evaluation of the proposed path based on all information gathered from the Linking and Termination domains. • Technology domain Linking domains can use a certain technology (such as pure optical circuits, SDH, SONET, Ethernet, etc.) in its switching/routing core. A Technology domain can allow ports to have a different technology then the Core (so adaptation taking place in the actual interface): e.g. an SDH Technology domain can have Ethernet ports. • Administrative domain [IDC: Domain] Networks fall under the strategic, tactic and operational responsibility of an entity e.g. NREN, operator, etc. Such an entity is called an Administrative domain. (Remember sometimes these three responsibilities can be done by three parties) • Provisioning domain A Provisioning domain is a Linking domain, which is defined by its provisioning methodology instead its technology. E.g. some NRENs (Administrative domain) aggregate their networks into one Provisioning domain. An example is HEAnet with its native Ethernet and an L2 MPLS VLL networks (two different Technology domains), but these two use the same NorthBound interface to form one Provisioning domain (using one tool: BLUEnet tool). Other objects of Provisioning domains are networks that use certain types of control plane or common management tool (aka north bound interface); like GMPLS, UCLP, DRAC, human NOC • Neighbouring domain A Neighbouring domain is a Linking/Termination domain that is physically connected (layer 0) to an adjacent Linking domain for the path. Neighboring domain is a Peering domain at layer 0. The proposed path (LIDP) is build of multiple Neighbouring domains. • Peering domain A Peering domain is the next domain where a certain protocol layer is terminated. This does not have to be the Neighbouring domain. For example two IP workstations interconnected with Ethernet network, the Peering domain of the IP layer are at the two workstations (User domains) which are not the directly connected Neighbouring domain. • Aggregated domain One can groom/group Administrative/Technology/Provisioning domains together over a large community and if that community acts as a single entity then we call this an Aggregated domain. UCLP is e.g. defined over many organisations, so it can be seen as a single Aggregated domain. This can also be used for groomed/grouped together networks for Premium IP (PIP) or (G)MPLS. An Aggregated domain could be a Termination or a Linking domain. Hope this helps in the discussion. I am planning to be by phone at the Tuesday meeting of OGF-NML. All the best, Victor -- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/
Hello all of you, Here are the slides of the meeting. Add ingress/egress and removed question mark from IDC name. All the best, Victor Victor Reijs wrote:
Hello all of you,
A few changes to the pdf file (learnt some more UML). I also added the IDC domain names in the below text.
So I am looking at the classes of domains which might be important when working on Stitching (which is trying to connect different domains together by checking if they are or can be made compatible).
This work has been done as part of AutoBAHN (GN2 JRA3 activity). The document that describes this Stitching Framework (SF) is here: http://www.geant2.net/upload/pdf/GN2-07-066v5-DJ3-5-3-Report_on_Testing_of_T...
This is already an 'old' document (1 year) and was also presented at GLIF in Japan (2006): http://www.glif.is/meetings/2006/controlplane/reijs-jra3.pdf <remember this is all before I knew UML, so it is not using that right UML terminology!>
I talked with Freek and we discussed the domains that could be important for NML and I proposed to make an overview of the 'domains' (classes and objects in UML language) which are handy (but not always essential!) in the SF. The SF is just one view of reality (a use case), so there might be less classes (more objects) or more classes (less objects) when looking at all use cases of domains. At least the ones I discuss were in some way handy when talking about stitching (the ones with a * at the end look to be important for path finding and stitching).
The below list comes from the above GEANT2 document (section 2.2.1) and I tried to UML-ize it (but I am really a novice on UML!). <I am still not 100% confident when to use classes, objects, attributes or values in UML, I am working on that>
I tried to check the terminology used within AutoBAHN and IDC (but I did was not able to fully cover this). It also is written from the view of Bandwidth on Demand (circuits), but it can just as well work in packet switched networks, application environment and/or political levels;-) So anywhere compatibility is needed.. Remember I might use IDC and AutoBAHN as examples, but they might not have implemented it!!! I also did not check it with NMWG doc. 'Hierarchy of Characteristics', which is I assume: http://www-didc.lbl.gov/NMWG/docs/draft-ggf-nmwg-hierarchy-02.pdf ?
The domain classes that play a some role in the use case, which uses the SF, are : • Termination domain This domain is where the possible path begins or ends. At least two Termination domains must exist in each path. A Termination domain can be a single workstation or a full-blown network (with demand for multiple paths). The Termination domain is not managed by the service (like AutoBAHN/IDC). It has only one 'side' (egress at start of the path and ingress at end of the path).
• User domain* [AutoBAHN: UserAccessPoint?] [IDC: End-User] A User domain is a kind of the Termination domain and it is where the actual User’s system/network resides.
• Linking domain* [AutoBAHN: External?] A Linking domain has known interfaces/protocols/processes and is one of the domains that make up the possible path between two Termination domains. If a proposed path (LIDP: Loose Inter-Domain Path) is possible all Linking domains together will form the actual path (SIDP: Strict Inter-Domain Path) (like AutoBAHN or IDC). A linking domain has two 'sides' (ingress and egress)
• Home domain The Home domain is the domain that will accept the BoD request from a User. The Home domain does not have to be an actual Linking domain in the path; the Home domain is just the domain where the User sends his/her BoD request. So the Home domain acts as a proxy to the service and determines the Source Domain).
• Source domain* [AutoBAHN: HomeDomain?] [IDC: Source/Endpoint] This is the first Linking domain that is part of the possible path. It might starts the investigation if a the BoD request can be made.
• Destination domain* [AutoBAHN: LastDomain?] [IDC: Destination/Endpoint] This is the last Linking domain that is part of the possible path. It might do the path finding and feasibility evaluation of the proposed path based on all information gathered from the Linking and Termination domains.
• Technology domain Linking domains can use a certain technology (such as pure optical circuits, SDH, SONET, Ethernet, etc.) in its switching/routing core. A Technology domain can allow ports to have a different technology then the Core (so adaptation taking place in the actual interface): e.g. an SDH Technology domain can have Ethernet ports.
• Administrative domain [IDC: Domain] Networks fall under the strategic, tactic and operational responsibility of an entity e.g. NREN, operator, etc. Such an entity is called an Administrative domain. (Remember sometimes these three responsibilities can be done by three parties)
• Provisioning domain A Provisioning domain is a Linking domain, which is defined by its provisioning methodology instead its technology. E.g. some NRENs (Administrative domain) aggregate their networks into one Provisioning domain. An example is HEAnet with its native Ethernet and an L2 MPLS VLL networks (two different Technology domains), but these two use the same NorthBound interface to form one Provisioning domain (using one tool: BLUEnet tool). Other objects of Provisioning domains are networks that use certain types of control plane or common management tool (aka north bound interface); like GMPLS, UCLP, DRAC, human NOC
• Neighbouring domain A Neighbouring domain is a Linking/Termination domain that is physically connected (layer 0) to an adjacent Linking domain for the path. Neighboring domain is a Peering domain at layer 0. The proposed path (LIDP) is build of multiple Neighbouring domains.
• Peering domain A Peering domain is the next domain where a certain protocol layer is terminated. This does not have to be the Neighbouring domain. For example two IP workstations interconnected with Ethernet network, the Peering domain of the IP layer are at the two workstations (User domains) which are not the directly connected Neighbouring domain.
• Aggregated domain One can groom/group Administrative/Technology/Provisioning domains together over a large community and if that community acts as a single entity then we call this an Aggregated domain. UCLP is e.g. defined over many organisations, so it can be seen as a single Aggregated domain. This can also be used for groomed/grouped together networks for Premium IP (PIP) or (G)MPLS. An Aggregated domain could be a Termination or a Linking domain.
Hope this helps in the discussion. I am planning to be by phone at the Tuesday meeting of OGF-NML.
All the best,
Victor
-- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/
participants (2)
-
Victor Reijs -
Victor Reijs (work)