[Nsi-wg] [Nml-wg] Conversation about ITU concepts with Ciena folks

Jerry Sobieski jerry at nordu.net
Mon Sep 14 15:23:27 CDT 2009


Hi folks-

The discussion below makes me think we need to explicit about the 
difference between the "user data payload" and the "framing protocol".  
  The former is the information that is to be transported [unmodified] 
from the source to the destination within a circuit, the latter is that 
information placed on a link in addition to or surrounding the user data 
that allows the user data to be recovered or routed.   The User Data 
Payload should always be delivered at the egress point just as it was 
accepted at the ingress point.  But the network is free to do whatever 
it has to within the network to transport it (e.g. segmentation and 
reassembly, transport protocol adaptations, etc.) 

I think this explicit terminology will allow us to be clear about what 
is the user data payload at any point in the circuit, and what is the 
outer layer of transport framing protocol.

I would also define two other terms:  "access" framing protocol, and the 
"transport" framing protocol.  The former defines framing protocol that 
delivers the user data payload to the ingress point of a circuit (or how 
it is delivered at the egress point), where the latter defines the 
framing protocol(s) used within the network to transport the user data 
(and of course, the latter may be different along different segments of 
the circuit).  

These terms I think will help us be clear as we discuss things like 
tunneling and when we encapsulate ot de-encapsulate circuit segments and 
protocols.

Jerry



John Vollbrecht wrote:
>> Jeroen van der Ham wrote:
>>
>> - layers come and go. We got rid of the ATM layer, and some people try
>> to get rid of the SONET layer(s). However, just the same, we add
>> (sub)layers for Ethernet and OTN.
>> - The order can not be fixed: it is getting common to see network
>> tunnels, e.g. Ethernet over IP over Ethernet, or simply Ethernet over
>> Ethernet (think Q-in-Q).
> I am wondering if layers are different if they are Q-in-Q or Ethernet 
> over IP.  Seems there needs to be an adaptation between these, but the 
> client info stays the same.  It seems to me that collapsing layers 
> where the client info stays the same and only the characteristic info 
> changes can be useful.
>
> Where adaptations do not exist between specific layers it seems silly 
> (at least to me) to flatten the topology.
> Where adaptations are not possible between layers  - one cannot adapt 
> a VLAN portion of a fiber, at least not without another adaptation 
> (e.g. SONEHi folks-T) between them.
I would agree that an Ethernet frame carried Q-in-Q would need to be 
adapted somehow to the EoIP environment.  The router does this but you 
need to tell it whether to encapsulate the whole inbound ethernet frame 
into IP packets, or to strip the inbound [outter] ethernet frame off, 
and simply forawrad the Q-in-Q frame over the IP link.  

I think  we should distinguish between the link layer protocol which is 
the protocol that actually carries data on a physical link, from what I 
call the "access" protocol - the protocol that  is used to present data 
at the ingress or egress points of a circuit.  (There maybe other terms 
used for these...these are what I use).   The di
>>
>> My concern about layer collapsing is how it handles multiplexing and
>> inverse multiplexing. A SONET circuit in the GLIF community may carry
>> multiple Ethernet connections. At my work, we have an immediate problem
>> that we must describe the relations between these connections -- if the
>> SONET circuit goes does, so will the Ethernet circuits, and our software
>> must know this relations or we will not inform the correct customers.
>> Therefor, we need a network description that is able to describe this
>> relation. I have doubts that this can still work for collapsed 
>> topologies.
>>
> I think this is probably a valid concern.  However I don't completely 
> understand it.  Is this the case where lower layers are carrying 
> multiplexed upper layer connections and one needs to know which upper 
> layer connections are being carried at the lower layer so that if it 
> fails the upper layer can be notified?
>
> If so it seems that the lower layer is a Link which carries segments 
> of the upper layer and if it goes down the upper layer link goes 
> down.  It is then the upper layer's job to notify its users that the 
> link is down.
>
>> Regards,
>> Freek
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nml-wg
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20090914/adeb9e18/attachment.html 


More information about the nsi-wg mailing list