Re: [802.1] Re: [PWE3] Next Generation CO-PS layer network technology?

[Loa Andersson <[e-mail]>]

MPLS and TEWG,

this is a mail that has been on the PWE3 mailings list, since it
concerns the tewg and mpls wg, I'm forwarding it the working
group mailing lists also.

As Stewart says it is interesting, but I often find it more
interesting to read things I disaggree with, than things I aggree with.

My take is that CO-MPLS is out of scope for the MPLS WG also.


/Loa

Stewart Bryant wrote:

>
> Maarten
>
> Although this is interesting work, it does not seem to fall
> within the charter of PWE3.
>
> The PWE3 charter is concerned with the emulation of services
> over the PSN infrastructure for which the IETF is the design
> authority. PWE3 would be the right place to consider EMULATING
> CO-MPLS over an IETF specified PSN, but it is not the right
> place to design CO-MPLS.
>
> This work would seem to be better directed at the MPLS or
> TEWG working groups.
>
> - Stewart
>
> Akiva Sadovski wrote:
>
>> Hi Maarten,
>>   thank you for very interesting NG CO-PS summary. 1) However i'm 
>> wondering whether we really need *both* SNCP and SPRing at
>> initial stages of
>> NG CO-PS development.
>> 2) As far as i know, there were some SNCP-like mechanisms for 
>> Ethernet under
>> development, like draft-shah-extreme-eaps-00.txt
>>
>> My 2c,
>>   Akiva Sadovski
>>
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]]
>>> Sent: Friday, December 12, 2003 3:05 PM
>>> To: [e-mail]; [e-mail]; [e-mail]
>>> Subject: [PWE3] Next Generation CO-PS layer network technology?
>>>
>>>
>>> As we are approaching the end of the year 2003 and many of use looking
>>> forward to one or more weeks of vacation (to get rid of all left over
>>> vacation days), I would like to provide some food for your thoughts 
>>> under the Christmas tree.
>>>
>>> INTRODUCTION
>>> ------------
>>> I have the feeling that 2004 will become known in history as the year
>>> in which we selected/developed the Next Generation Connection Oriented
>>> Packet Switched (NG CO-PS) layer network technology, which will be the
>>> successor of FR and ATM. I would therefore like to initiate a 
>>> discussion
>>> on this topic.
>>>
>>> CURRENT LANDSCAPE
>>> -----------------
>>> When I look at the current NG CO-PS landscape, I see four alternatives
>>> that are being considered, discussed, investigated, developped and/or
>>> installed:
>>>
>>> 1) CO-PS MPLS (switched MPLS)
>>> 2) CO-PS ETH/VLAN (switched Ethernet/switched VLAN)
>>> 3) CO-PS GFP (switched GFP)
>>> 4) something new.
>>>
>>> The first three alternatives have as starting point the 
>>> re-use/multi-use of existing popular frame/packet formats:
>>> 1) MPLS packet with its shim header (label, EXP, S, TTL):
>>> 2) tagged MAC frame (ethertype, VLAN ID, priority, CFI)
>>> 3) GFP-F frame with linear extension header (Channel ID, spare).
>>>
>>> BASIC NG CO-PS CHARACTERISTICS
>>> ------------------------------
>>> NG CO-PS frame/packet format needs to support the following fields:
>>> a) tributary slot identifier (label, VLAN ID, channel ID)
>>> b) class of service/dropping precedence (EXP, priority)
>>>
>>> NG CO-PS frame/packet format needs to support the following 
>>> networking capability:
>>> c) multi-level hierarchy (tunneling) capability to allow it to
>>>   be used in (metro-)access, metro(-core) and core networks.
>>>
>>> NG CO_PS technology needs to support connection monitoring according
>>> the G.805 paradigm; this includes:
>>> d) connection monitoring for each (tunnel) level in the hierarchy
>>> e) multi-level (nested) connection monitoring capability for user   
>>> connections, to allow dedicated connection monitoring for user,
>>>   service provider and network operator(s) as well as for protection
>>>   and restoration.
>>> f) pro-active fault management and performance monitoring OAM for   
>>> user connections and hierarchy levels (tunnels)
>>> g) on-demand fault localisation OAM for user connections and
>>>   hierarchy levels.
>>> Note: Non intrusive monitoring of any connection monitoring level at
>>> an intermediate point in the connection for the service provider is a
>>> requirement for today's SDH/SONET and OTH networks, in the absence of a
>>> standard "service management" architecture. With the work on the 
>>> Architecture for Services Management (G.asm) being started in Q.12/15,
>>> the NG CO-PS may not require this non-intrusive connection 
>>> monitoring of any connection monitoring level. This removes a 
>>> significant requirement.
>>>
>>> NG CO-PS technology needs to support connection oriented protection
>>> and restoration; this includes:
>>> h) subnetwork connection protection (SNCP)
>>> i) ring protection (SPRing).
>>>
>>> NG CO-PS layer network needs to support:
>>> j) client/server relationships (mapping, network interworking)
>>> k) G.805 layer network interworking (service interworking)
>>> with existing CO-PS layer network technologies.
>>>
>>>
>>> EVALUATION OF CURRENT FRAME FORMATS
>>> -----------------------------------
>>> The MPLS packet format is considered as it provides the closest 
>>> match with
>>> the basic characteristics required for the NG CO-PS technology.
>>>        a) trib slot id: 20-bit label
>>>        b) CoS/DP: 3-bit EXP
>>>        c) hierarchy: infinite tunneling capability
>>>        d) tunnel conn. mon.: MPLS OAM
>>>        e) nested conn. mon.: MPLS OAM
>>>        f) pro-active fm/pm: MPLS OAM (CV, FFD, FDI, BDI)
>>>        g) on-demand fault loc.: MPLS OAM (ping)
>>>        h) SNCP: MPLS protection switching
>>>           Further enhancements/extensions are required.
>>>        i) SPRing: to be developed
>>>        j) mapping: IP: available, ATM, FR, ETH: under development
>>>        k) LN IW: MPLS/ATM, MPLS/FR under development.
>>> By using MPLS as the NG CO-PS packet format, the "M" in MPLS gets a 
>>> second
>>> meaning; this "M" originally referred to it being a protocol that 
>>> can ride
>>> over multiple server layer protocols, with the deployment as NG 
>>> CO-PS it also refers to multiple client layer protocols that can 
>>> ride over it.
>>>
>>>
>>> The Ethernet MAC tagged frame format is considered due to the low cost
>>> of today's ethernet interface ports. The Ethernet MAC frame is 
>>> developed
>>> for use in bridged-ethernet networks; its use as NG CO-PS would 
>>> require a
>>> number of extensions:
>>>        a) trib slot id: 12-bit VLAN ID
>>>        b) CoS/DP: 3-bit priority
>>>        c) hierarchy: potential VLAN stacking capability
>>>           Requires new CO-PS VLAN tags to be defined; QTag and
>>>           STag should not be used as these are for bridged-ethernet, 
>>> not
>>>           for switched-ethernet/VLAN.
>>>        d) tunnel conn. mon.: to be developed
>>>        e) nested conn. mon.: to be developed
>>>        f) pro-active fm/pm: to be developed
>>>        g) on-demand fault loc.: to be developed.
>>>           The current bridged-ETH OAM development in Q.3/13 may be
>>>           the basis for d) to f)
>>>        h) SNCP: to be developed
>>>        i) SPRing: to be developed
>>>        j) mapping: IP, MPLS: available, ATM, FR: ?
>>>        k) LN IW: ETH/ATM, ETH/FR, ETH/MPLS to be developed?
>>>        x) development of connection oriented VLAN switching.
>>> Switched-Ethernet/VLAN will use the ethernet MAC frame as encapsulation
>>> format for multiple client signals. The implication of this is to be
>>> understood.
>>>
>>>
>>> The GFP-F frame format is considered as it is the latest frame format
>>> developed within the standards organisation (ITU-T) that traditionally
>>> defines connection oriented layer technologies. GFP-F is an 
>>> encapsulation
>>> frame format and its use as NG CO-PS would require a number of 
>>> extensions:
>>>        a) trib slot id: 8-bit channel ID
>>>           D.371 (SG15, 04/02) proposes a 20-bit Flow ID.
>>>        b) CoS/DP: to be developed
>>>           D.370 (SG15, 04/02) proposes a 3-bit Priority field.
>>>        c) hierarchy: to be developed
>>>           Requires capability to support stacking in the extension 
>>> header.
>>>           58 bytes are available in the extension header area for such
>>>           purpose. With e.g. 3-bytes per level (20-bit label, 3-bit 
>>> CoS/DP,           1-bit bottom of stack), 19 levels can be supported.
>>>        d) tunnel conn. mon.: to be developed
>>>        e) nested conn. mon.: to be developed
>>>        f) pro-active fm/pm: to be developed
>>>        g) on-demand fault loc.: to be developed.
>>>        h) SNCP: to be developed
>>>        i) SPRing: to be developed
>>>        j) mapping: to be developed
>>>        k) LN IW: to be developed
>>>        x) development of connection oriented GFP switching.
>>>
>>>
>>> CO-EXISTENCE
>>> ------------
>>> For the case we will select one of the three existing frame/packet 
>>> formats
>>> as basis for the NG CO-PS layer network, it will have to peacefully 
>>> co-exist
>>> with the original application; i.e. the NG CO-PS development should 
>>> not hijack
>>> the frame/packet format. This requires cooperation and recognition 
>>> of the needs
>>> of both the original and the new NG CO-PS application.
>>>
>>> If the current "owners" of the frame/packet formats (MPLS: IEFT, 
>>> MAC: IEEE 802,
>>> GFP-F: ITU-T SG15) are not able/do not want to share their 
>>> frame/packet format
>>> with the new NG CO-PS application, that frame/packet format should 
>>> not be
>>> considered as a NG CO-PS frame/packet format candidate.
>>>
>>> I am therefore very interested to hear the opinion of the 
>>> participants of IETF, IEEE 802 and ITU-T SG15 on the multi-use of 
>>> their frame/packet format as NG CO-PS
>>> frame/packet format.
>>>
>>>
>>> EQUIPMENT
>>> ---------
>>> The NG CO-PS layer network will introduce one additional switching 
>>> technology or
>>> switching technology profile in the multi service switching 
>>> platforms (MSSPs).
>>>
>>> Some existing MSSPs may already support elements of the NG CO-PS 
>>> and/or may be
>>> upgradable to support NG CO-PS. Others may not support any element 
>>> of the NG CO-PS
>>> and may not be upgradable. That's just how life is; it should not 
>>> play a major role
>>> in the decision process for the NG CO-PS in my opinion.
>>>
>>>
>>> Up to so far. Looking forward to your opinions on this item.
>>>
>>> Regards,
>>> Maarten
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Maarten Vissers
>>> Network and Product Strategy - Optical Networks Division
>>> Alcatel SEL AG Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
>>> Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
>>> Mobile: [phone]
>>> Email:[e-mail]
>>>
>>> _______________________________________________
>>> pwe3 mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/pwe3
>>>
>>
>>
>> _______________________________________________
>> pwe3 mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/pwe3
>>
>>
>
>
> =>IEEE 802.1 Email List user information:
> http://www.ieee802.org/1/email-pages/
>
>

-- 

Loa Andersson

mobile [phone]