RE: Next Generation CO-PS layer network technology?

[Akiva Sadovski <[e-mail]>]

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
>