[Nml-wg] domains and the Stitching Framework (SF) version 2

Victor Reijs (work) victor.reijs at heanet.ie
Tue Jun 3 06:03:56 CDT 2008


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_Technology_Stitching.pdf 
> 
> 
> 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: domainsinSF-02.ppt
Type: application/vnd.ms-powerpoint
Size: 302080 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nml-wg/attachments/20080603/554eae06/attachment-0001.ppt 


More information about the nml-wg mailing list