[Nml-wg] DCN glossary

Tue Jul 1 10:02:17 CDT 2008

Ralph -

Thanks for the discussion -

I think this raises a question about how one thinks about paths and  
links.  I think one difference between IP and dynamic circuits is  
that dynamic circuits require setting up ete circuits and reserving  
resources for the circuits.  These reservations are done resource  
providers.  We tend to think of a "domain path segment"' as being  
between provider end points.  Other segments or paths could end, as  
you point out, at the incoming link on the remote equipment.

Since either way the end of the path is on the same link, the  
question is why it makes a difference.  If the end is on the provider  
side, then the provider is able to set up all parts of the circuit  
and monitor it.  What is requested of a provider is something he can  
provide.  I note that in our user interface we allow request for  
circuits to be made between devices (i.e. the user side of the link)  
and the user interface converts it to provider endpoint links before  
forwarding it to the provider.   This allows requesting connection  
from user interface (as in IP) and then requesting from the provider  
what it is able to provide.

For monitoring we assume that both sides of an interdomain link  
segment can be monitored by their respective domain.  The link  
segment between user and provider (or provider and provider) has  
different names at each end of the link, and the topology must  
describe this.  The reason for different names at each end is that  
the domain must be part of the name in each case.  Thus interdomain  
links have two names for what (if all works correctly) is the same  
link.  Monitoring at each end assures that the segment is not broken.

I think perhaps there needs to be some qualification of what sort of  
path is required - i.e. a user - user path or an network provider  
path.  What do you (and others) think?  I think that once a provider  
path is complete, users at each end must also verify that the path is  
operational, at that point the path includes users.

John

On Jul 1, 2008, at 9:55 AM, Ralph Niederberger wrote:

> Dear John and all,
>
> only some information which could influence some definitions.
>
> I had some discussion with GARR (Italian NREN) concerning Endpoint  
> and Demarcation point
> of an E2E path. Background is the following:
>
> GEANT2 provides wavelength throught their infrastructure which can  
> be prolonged on both sides by
> wavelengths of NRENs. DEISA has rent such a kind of 10 Gbit/s End  
> to End Service (e2e).
>
> E.g.
> DEISA site FZJ Juelich, Germany <-> fiber cable
>       < -> DWDM equipment at PoP of local NREN DFN in Juelich,  
> Germany <-> fibre cable with DWDM
>               <-> DWDM equipment of local NREN DFN at GEANT2 PoP in  
> Frankfurt, Germany <-> fibre cable
>                      <-> DWDM equipment of GEANT2 at Frankfurt,  
> Germany <-> fibre cable with DWDM
>                             <-> DWDM equipment of GEANT2 at London,  
> UK <-> fibre cable
>                                    <-> DWDM equipment of remote  
> NREN JANET <-> fibre cable with DWDM
>                                            <-> DWDM equipment at  
> PoP of remote NREN JANET at Daresbury, UK <-> fibre cable
>                                                   <-> DEISA remote  
> site EPCC Daresbury, UK
>
> For monitoring purposes the "GEANT2 End2End Coordination  
> Unit" (E2ECU) has setup a
> domain related monitoring tool.
> Each domain provides its information of the path (e.g. Path is  
> administratively or operationaly up or not).
> Measurement points between domains are demarcation points.
> Both ends of the link between two domains provide partial  
> information. So concerning to this definition
>
> GARR argues that the end of the provider links are the end point of  
> the path, i.e. the outgoing interfaces of
> the DWDM equipment.
>
> IMHO the ends of the path are the incoming interfaces of the two  
> sides which have requested the e2e path.
>
> So your definition would give room for some interpretation:
> "path - a connection between a source and destination.  A path is a  
> sequence of hops."
> We all know, that we assume as path (at least within IP) the  
> connection from source (outgoing interface)
> to destination (incoming interface). But others (e.g. Service  
> providers) could argue in a different way.
> best regards
>
> Ralph
> John Vollbrecht schrieb:
>> Attached is a DCN glossary which is part of DCN architecture and  
>> DCN reservation documents.
>>
>> Of particular note are some terms we  use that don't seem to be in  
>> the NML schema (perhaps I am wrong?)
>>
>> path - a connection between a source and destination.  A path is a  
>> sequence of hops.
>> source - starting point of path - as defined by direction of  
>> signalling
>> destination - end point of path- as defined by direction of  
>> signalling
>> hop - a network element - [domain or node or port or link]
>>
>> path segment - subset of a path consisting of two or more hops
>> circuit - a connection between tow endpoints that can be used to  
>> transmit data between them
>>
>> I note that in the glossary some information is assumed, in at  
>> least some of the definitions.  In particular, a path (perhaps a  
>> DCN path) must include time/duration and resource.  That is, a  
>> Link may carry multiple paths at a given time, and may carry  
>> different paths sequentially.
>>
>> I am wondering if this or something like it can be incorporated  
>> (or is incorporated) in NML.
>>
>> John
>>
>>
>>
>>
>> John Vollbrecht, Senior Network Engineer
>> Internet2
>> office +1-734-352-4960 | mobile +1-734-395-7890
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nml-wg
>>
>
> -- 
>
> ***************************************************
> Ralph Niederberger
> Juelich Supercomputing Centre
> Institute for Advanced Simulation
>
> Phone:  +49 2461 61-4772
> Fax:    +49 2461 61-6656
> E-Mail: r.niederberger at fz-juelich.de
> WWW:    http://www.fz-juelich.de/jsc/
>
> JSC is the coordinator of the
> John von Neumann Institute for Computing
> and member of the
> Gauss Centre for Supercomputing
> ***************************************************
>
> Forschungszentrum Jülich GmbH
> 52425 Jülich
>
> Sitz der Gesellschaft: Jülich
> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
> Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
> Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
> Dr. Sebastian M. Schmidt
> ***************************************************
>
>

John Vollbrecht, Senior Network Engineer
Internet2
office +1-734-352-4960 | mobile +1-734-395-7890