Transcript PowerPoint 演示文稿

Welcome to join Tutorial
An Introduction to
LAPS and MSR Applications
To the March 2004 SG17 Meeting
Q.7/17 Rapporteur
Our Liaisons and Communications
Leader
SG17
P802.17
IETF
Q.7/17
SG15
SG13
X.85/Y.1321 (IP over SDH using LAPS) milestone
1、Delay contribution, August 1998
2、It was acceptable by ITU-T SG7(Data network and Open
System Communication) at the September meeting, 1998
3、X.85/Y.1321 on IP over SDH using LAPS was determined at the
June 1999 meeting
4、Recommendation X.85/Y.1321) was approved at March 2000
meeting,
then new version is available Feb. 2001
X.85/Y.1321 Comments received
1、IETF and ISOC
2、ITU-T SG15 (Optical and other transport networks)
3、ITU-T SG11 (Signaling requirements and protocols)
4、ITU-T SG13 (Multi-protocol and IP-based networks and their
internetworking)
6、Nortel
7、NTT
8、Swisscom
9、Lots of email from Vendors and Carriers
Why LAPS (X.85)
1、Simple implementation
2、High efficiency in the POS line card of router
3、Function equivalent to PPP/HDLC
4、Performance of Carrier concern
5、Compatibility with PPP/HDLC
6、Test equipment (share POS)
Note: PPP is widely deployed in networks around the world and has been
updated and extended over the last 14 years. These slices just emphases a
simple LAPS method of high-speed link (e.g. POS) and also provide
compatibility with PPP/HDLC.
Why LAPS (X.85)
IP
IP
PPP
HDLC
SDH/SONET
PPP over SDH/SONET
LAPS
SDH/SONET
IP over SDH
Why LAPS (X.85)
The diagram of Router
Line
Card 0
Line
Card 7
Switch
Fabric
Line
Card 1
Line
Card 8
Scheduler
Line
Card 6
Line
Card 10
RE
RE or
LC11
Why LAPS (X.85)
POS Line Card
O/E
STM-16c
Transceiver
POS PHY
POS
Framer
Network
Processor
I/F
Switch
Fabric
Memory
POS Line Card
16 x 16
SPI-4.2
O/E
STM-16c
Transceiver
POS
Framer
Network
Processor
Memory
POS Line Card
I/F
Routing
Engine
Why LAPS (X.85)
Local node
LCP
Software
Routing
Engine
SNMP
RIP
UDP
BGP
TCP
OSPF
Hardware
IP
Forwarding
Engine
Filter Function
Fwd/Rcv to/from
Adjacent Node
PPP,LCP,IPCP
POS PHY/Utopia3 Reference Point
HDLC
SDH/SONET
Protocol processing of signaling and Traffic plane
Why LAPS (X.85)
• The major objective of X.85 is to remove PPP
protocols including LCP and IPCP in the case
of POS.
•LCP contains 10 configuration packets,16
events, and 12 actions.
Why LAPS (X.85)
X.86 vs. RFC 2615 (frame)
RFC 1662 frame
RFC 1661 frame
Flag
Address
01111110
11111111
Flag
Address
01111110
Protocol
PPP
00000011 8/16 bits
PDU
Control
Control
00000100 00000011
FCS
Padding
Flag
16/32 bits 01111110
SAPI
IPv4 and IPv6
FCS
Flag
16 bits
PDU
32 bits
01111110
X.85 frame
Why LAPS (X.85)
X.85 vs. RFC 2615, specifications including functions
and related Network management
RFC 2615：RFC 1661
RFC 1662
RFC 1570
RFC 1547
RFC 1340
SNMP & MIB
X.85
SNMP & MIB
Why LAPS (X.85)
LAPS or POS HDLC Framer/Deframer functions:
T
R
Insertion of HDLC frame into the SPE
Framing,
Inter-frame fill and transmit FIFO error recovery.
Scrambling (X**43 +1),
Transparency processing
generate a 16/32 bit FCS.
Extraction of HDLC frame,
Transparency removal,
De-scrambling (if enable),
FCS error checking,
Optional delete the HDLC address and control fields.
Why LAPS (X.85)
1、Simple implementation
2、High efficiency in the POS line card of router
3、Function equivalent to PPP/HDLC
4、Performance of Carrier concern
5、Compatibility with PPP/HDLC
6、Test equipment (share POS)
Why LAPS (X.85)
Comparison of Protocol states：
RFC 2615：2+137，
LAPS：2
Why LAPS (X.85)
1、Simple implementation
2、High efficiency in the POS line card of router
3、Function equivalent to PPP/HDLC
4、Performance of Carrier concern
5、Compatibility with PPP/HDLC
6、Test equipment (share POS)
Why LAPS (X.85)
RFC 2615（PPP/HDLC）
LAPS
Protocol encapsulation
yes
yes
Inter-frame fill
yes
yes
Scrambling
yes
yes
Transparency
yes
yes
FCS
yes
yes
Link status monitoring
Yes
yes
Configuration Req./Ack/Nak
yes（padding function）
Terminate Req./Ack
yes（but it is seldom used）
Protocol Reject
yes（but it is seldom used）
Echo Req./Reply
yes
Discard Req.
yes（but it is seldom used）
yes in SDH/SONET
Why LAPS (X.85)
1、Simple implementation
2、High efficiency in the POS line card of router
3、Function equivalent to PPP/HDLC
4、Performance of Carrier concern
5、Compatibility with PPP/HDLC
6、Test equipment (share POS)
Why LAPS (X.85)
The Diagram of Network Processor
SSRAM
Input
stream
parsing
Receive
editor
Queue
mgnt.
Fabric I/F
Pre-search
queue
Output
scheduler
Queue
mgnt.
Sending
Stream
editor
CPU I/F
CPU
Statistics &
internal registers
SDRAM
Switch Fabric
scheduler
System I/F
Framer/Deframer
Search &
update
SDRAM
Why LAPS (X.85)
L7
Application
L6
Presentation
L5
Session
L4
Transport
L3
Network
L2
PPP、LCP 、 IPCP
L2
HDLC
L1
Physical Layer
Open System Interconnection
End system
Intermediate system，40-1600 bytes
Intermediate system ，10 bytes
Why LAPS (X.85)
RFC 2615(PPP/HDLC)
MPS/mPS
1600/10=160
Latency
LAPS
Cell based
1600/40=40
1
NP
NP
Latency variance
4 times
－
good
Packet loss
4 times
－
very low
Capability of
Jumbo payload
processing
Congestion
QoS
relative lower
processing capability low
3 times lower
relative power
good
middle
relative high
normal
good
Why LAPS (X.85)
1、Simple implementation
2、High efficiency in the POS line card of router
3、Function equivalent to PPP/HDLC
4、Performance of Carrier concern
5、Compatibility with PPP/HDLC
6、Test equipment (share POS)
Why LAPS (X.85)
Node1
PPP/HDLC
GbE
LAPS
Node5
PPP/HDLC
LAPS
Node2
Node4
GbE
PPP/HDLC
LAPS
Node3
Why LAPS (X.85)
How LAPS compatible with PPP/HDLC
IP
IP
PPP
HDLC
SDH/SONET
PPP over SDH/SONET
IP
PPP
LAPS
SDH/SONET
IP over SDH
LAPS=HDLC
SDH/SONET
PPP over SDH using LAPS
Why LAPS (X.85)
X.86 vs. RFC 2615
RFC 1662 frame
RFC 1661 frame
Flag
Address
01111110
11111111
Flag
Address
01111110
Protocol
PPP
00000011 8/16 bits
PDU
Control
Control
00000100 00000011
FCS
Padding
Flag
16/32 bits 01111110
SAPI
IPv4 and IPv6
FCS
Flag
16 bits
PDU
32 bits
01111110
X.85 frame
Why LAPS (X.85)
When the PPP is used to be encapsulated via SAPI for the compatibility with
RFC 2615, it is noted:
(1)Both FCS-32 and FCS-16 can be set by provisioning and is not negotiated.
The 32-bit FCS must be used for all SDH rates. For STM-1c/VC-4 only, the 16bit FCS may be used, although the 32-bit FCS is recommended.
(2)Regarding the path signal label (C2) of SDH, for compatibility with RFC
2615, the signal label value of (x43 + 1) scrambling is changed from 24 (18
hex) to 22 (16 hex). Additionally, the LAPS does also provide the signal label
value 207 (CF hex) to indicate PPP without scrambling.
(3)The data link will be operated as RFC 2615 defines and the Address field is
set to “11111111”, the padding field followed information field and the functions
of Link Control Protocol and Network Control Protocol will be included.
Why LAPS (X.85)
1、Simple implementation
2、High efficiency in the POS line card of router
3、Function equivalent to PPP/HDLC
4、Performance of Carrier concern
5、Compatibility with PPP/HDLC
6、Test equipment (share POS)
Why LAPS (X.85)
Testing equipment
1、Smartbits are used to throughput
2、RouterTest/Adtech is used to traffic and routing
protocols
X.86 (Ethernet over SDH/SONET)
introduction
LAPS (X.86) milestone
1、Delay contribution from May 1999
2、It was acceptable by ITU-T SG7(Data network and Open
System Communication) at the June meeting, 1998
3、X.86 on Ethernet over LAPS was determined at the
March 2000 meeting
4、Recommendation X.86 on Ethernet over LAPS (TD
2046/Rev.1) was approved at Feb. 2001 meeting, ten
months earlier than that of GFP
LAPS (X.86), three types of application
155Mbps
SDH
2.5Gbps
SDH
1
Ethernet
SONET/WDM
Ethernet
EOS
GE
2.5Gbps
3
155Mbps
EOS
GE
EOS
GE
Ethernet
EOS
FE
Ethernet
Ethernet
2
1.Telecom based Switch
2.Datacom based SDH/SONET
3.2-port small box solution
ITU-T X.86
(Target at Ethernet over SDH/SONET)
Latency Variance Computation
Ethernet MAC -15μs
Rate Adaptation, Buffer -15μs
LAPS mapping, Buffer -15μs
LAPS CRC, Buffer -15μs
----------------------------------------Latency Variance Total:-60μs
GE on GE switch -4μs
The competitive advantages of X.86
• Remote Trail Performance Monitoring
• Remote Fault Indication
• IEEE802.3x – Active Flow Control in Burst Traffic Condition
• Low Price and Ease of Use (Compared to LANE)
• Low Latency and Low Latency Variance
• 1+1 redundancy based Ethernet and Gigabit Ethernet service
• Target at existing telecom transport resources
X.86 does match Ethernet and Gigabit Ethernet very well
Preamble
IFG
802.3 MAC Frame
+SFD
12 Bytes
8 Bytes
64 Bytes
=84 Bytes
Time Fill
Flag
1
Flag Addr
10
1
1
Cont
1
SAPI
802.3 MAC
32-Bit CRC
2
64
4
=84 Bytes
Flag
Understand GFP
16-bit PAYLOAD
LENGTH INDICATOR
Octet
Transmission
Order
cHEC
(CRC-16)
CORE
HEADER
PAYLOAD
HEADERS
(4-64 BYTES)
1
PLI
<15:08>
2
PLI
<07:00>
3
cHEC
<15:08>
4
cHEC
<07:00>
Octet
1
2
3
4
5
6
7
8
Bit
PAYLOAD
AREA
Bit Transmission Order
CLIENT
PAYLOAD
INFORMATION
FIELD
(1)Payload
(3)Optional Payload FCS
(4)PLI value
Octet
Transmission
Order
OPTIONAL
PAYLOAD FCS
(CRC-32)
(2)Payload Header
Octet
Transmission
Order
(5)cHEC computation
15 14 13 12 11 10
5
PTI
9
8
1
5
4
3
2
tHEC
2
Extension
Header
Field
.
.
.
Octet
UPI
6
Type
0 to 60
eHEC
2
Bit
EXI
PFI
6
7
5
6
7
8
9
Bit
1
2
3
4
5
6
7
Bit Transmission Order
2
1
2 3 4 5 6 7
Bit Transmission Order
Bit
0
8
8
Understand GFP
•HEC inherits from ITU-T Rec. I.432，Octet based spec.
• ATM is L2/L3 technologies, based on connection and
fixed packet size (cell), IP as a ATM client is flexible rate for
the IP over ATM applications in the most case; GFP is
L1/L2 technologies, based on connectionless and variable
packet size. For the L1-GFP, FE/GE as a GFP client is rigid
rate for the Ethernet over SDH applications in the most
case
• In terms of PDH(E1/T1/E3/E4), Jumbo Payload size of IPv6
can be greater to 64Kbits length due to GFP-PLI is 2-Octet
definition (216bits=64Kbits=8Kbytes)？If PLI is changed to
3-octet or more, how to keep compatibility with existing
GFP standard
• Flow control？Rate adaptation?
Understand GFP
Why Flow control? Why Rate adaptation?
(1)FE/GE Bandwidth≠VC or VCs concatenation Bandwidth
(2)No difference is applied for the two time-slice (TS) if
Ethernet data stream is mapped into VC overhead or/and
VC payload during two different time-slice
Mapping octet by octet
TS1
VC
overhead
VC
payload
TS2
Real-time
Understand GFP
•Issue of tiny-frame (7 bytes), Client Signal Fail (LOS of
Client Signal and Loss of Character Synchronization)？
•4-octet idle issue？
Understand GFP
tiny-frame issue for IPv4 over SDH using GFP(1)
L7
Application
L6
Presentation
L5
Session
L4
Transport
L3
Network
L2
GFP
L1
Physical Layer
Open System Interconnection
End system
Intermediate system，40-1600 octets
Intermediate system ，7 bytes
Understand GFP
tiny-frame issue for IPv4 over SDH using GFP(2)
Framer
Framer
Framer
Framer
Framer
Framer
网络处理器
网络处理器
网络处理器
网络处理器
网络处理器
Network
Processor
背板
背板
背板
背板
Backplane
背板
适配
适配
适配
Adaptation
适配
适配
Line Card
POS-PHY bus/SPI-4.2 bus
155M POS ---825M
622M POS --- 1650M
2.5G POS --- 32100M,6450M
Routing
and
signaling
Understand GFP
tiny-frame issue for IPv4 over SDH using GFP(3)
GFP
LAPS
MPS/mPS
1600/7=228
1600/40=40
Latency variance
great
middle
Cell based
1
MPS: Maximum packet Size, 1600 octets specified by IETF
mPS: Minimum Packet Size , 40 octets specified by IETF
little
Understand GFP
4-octet idle issue
Mapping relationship and timing,
FE/GE is mapped into GFP, LAPS and
RPR(LAPS/GFP)
Understand GFP
Ethernet
Frame
Preamble+SFD
IFG
12
IFG
64-1518
8
Preamble+SFD
8
12
64-1522 if VLAN
GFP
frame
4
4
Idle Idle
FCS
4
2
2
2
2
2
Idle PLI cHEC
2
tHEC eHEC
Type
CID+
Spare
GFP
Payload
4
4
4
2
Idle
Idle
Idle
PLI
FCS
Real Time
Case 1 - Octets Mapping of Ethernet using GFP
LAPS & GFP
68-1522 if VLAN
Ethernet
Frame
IFG
Preamble
+SFD
12
8
IFG
64-1518
1
X.86
Frame
3
2
1
10
Flag
Flag
1
1
1
Flag Addr. Ctrl
2
SAPI
4
LAPS Payload
Preamble
+SFD
12
5
8
6
4
FCS
1 N 1
1
Flag Flag Addr
Real Time
Case 2 - Octets Mapping of Ethernet using LAPS
LAPS & GFP
RPR idle format
LAPS & GFP
68-1522 if VLAN
Ethernet Frame
IFG
Preamble+SFD
12
8
Preamble+SFD
IFG
64-1518
12
8
64
6
1
RPR Frame
2
Ring Control
4
Idle
6
6
DA
SA
4
4
Idle
Idle
2
PLI
RPR
Payload
2
2
Next frame
8
Header CRC
Protocol Type
16
FCS
9
3
2
GFP frame
7
5
4
?
10
2
2
Type
cHEC
2
2
2
tHEC
CID+
Spare
eHEC
GFP
Payload
4
Idle
FCS
4
4
Idle
4
Idle
Packet Loss
2
4
PLI
Timing border
FCS
4
4
Variable
Idle
No Delay
1
2
3
Delay
4
5
6
1
2
7
3
4
8
5
Idle
Real Time
9 10
7
6
Variable
8
9 10
Variable
Variable
Case 3 - Octets Mapping of Ethernet/RPR/GFP
LAPS & GFP
68-1522 if VLAN
IFG
Ethernet Frame
IFG
Preamble+SFD
12
64-1518
8
Preamble+SFD
12
8
64
6
1
RPR Frame
2
Ring Control
1
Flag
6
6
DA
SA
N
Flag
1
Flag
RPR
Payload
2
2
Next frame
8
Header CRC
Protocol Type
16
FCS
9
3
2
GFP frame
7
5
4
Good
10
1
1
Addr
Ctrl
LAPS
Payload
2
4
Idle
SAPI
FCS
1
N
Flag
Flag
1 1
Flag
Timing border
FCS
N
1
Fixed
No Delay
1
2
3
Delay
4
1
Flag
Flag
5
6
1
2
7
3
4
8
5
No Packet Loss
Real Time
9 10
7
6
Variable
8
9 10
Variable
Variable
Case 4 - Bytes Mapping of Ethernet/RPR/LAPS
LAPS & GFP
Comparison of Measurement
GFP
64bytes
1518bytes
9.6Kbytes
10.520 µs
LAPS/X.86 Percentage
9.658 µs
203.620 µs 133.967 µs
-
769.567 µs
8.9%
51.9%
Advantage of using LAPS
• Flow-control and rate adaptation are very useful for
BW mismatch between Ethernet and SDH VC (or
concatenation) and time-slice difference between VC
overhead and VC payload
• Application of Both SDH and PDH(E1/T1/E3/E4) for
LAPS, Both SDH and PDH(DS3) for GFP
• High efficiency
• LAPS is compatible with POS and PPP/HDLC
• LAPS Idle(Flag) has good performance for linespeed Ethernet over SDH/SONET applications
• X.86 was approved ten months earlier than that of
GFP
LAPS & GFP
Disadvantage of LAPS and PPP/HDLC
(1) Escape Code
An Introduction to MSR Applications
•What is MSR?
•Why MSR?
•MSR Scope
•Multi-service capability
What is MSR(1)
TCE
Data
Node 1
First Working Ring
TCE (1)
FE (1)
FE (3)
Data
Node 6
GE
FE MSR
TCE
First Working Ring
Second Working Ring
POS
Data
Node 2
MSR(3)
TCE (1)
FE (2)
FE (4)
TCE (1)
TCE (3)
GE
TCE
Data
Node 3
Data
Node 5
MSR (1)
TCE (1)
TCE (2)
FE (5)
POS
Data
Node 4
TCE (1)
TCE (2)
MSR (2)
Aggregate Pipe
TCE (1)
TCE (2)
MSR (2)
What is MSR(2)
Station A
Small pipe: tributary
(just like PVC)
Station B
Big pipe: Aggregate
An Introduction to MSR Applications
•What is MSR?
•Why MSR?
•MSR Scope
•Multi-service capability
Basic Consideration(1)
• Focus on Metro
• Sync. to async., TDM to packet, Physical
transmission from SDH/SONET to MAC, Highorder VC and Lower-order VC to tributary (packet)
• MSPP/MSTP from TDM based to packet based
• Push multi-service transport issue to LLC(L2)
Basic Consideration(2)
• Differentiated SLA, controllable and
configurable service operation
• Static and dynamic resource management
• Both connection and connectionless
• Bridge and back-to-back connection between
MSR/RPRs
• Lower cost and little maintenance
Why MSR(1)
differentiates RPR transport capabilities and
provides multi-congeneric-service and multiheterogeneous-service transport including
Ethernet, Gigabit Ethernet, FR, G.702 PDH
circuit -- Synchronous and asynchronous circuit
transport, Video signal, voice-band signal, Digital
channel etc.
Why MSR(2)
Differentiates RPR ring protection function and
provides service (or tributary) based standby
(protection) of 1+1, 1:1, and 1:N models within
50 ms.
Why MSR(3)
Reassembly a single packet based multicast and
broadcast of RPR to form service (stream)
multicast and broadcast capabilities, and
provide Service (or tributary) based multicast
and broadcast.
Why MSR(4)
Adding bandwidth management function for
each service (tributary) and provides service
bandwidth management with either symmetry
or asymmetry.
Why MSR(5)
Adding bandwidth merging function for
congeneric-service (congeneric-tributary) and
provides tributary merging with either
symmetry or asymmetry.
Why MSR(6)
Adding the simple security filtering function for
each tributary service and provides line-rate
filtering to monitor and manage service security.
Why MSR(7)
Adding the performance management function
for each tributary service and provides
tributary performance monitoring in 15-minute
and 24-hour.
Why MSR(8)
•QoS Guarantee
•Customers separation
•Addresses separation
•Topologies separation
Why MSR(9)
Topology supported
•Two fiber ring
•Link
•Broadcast topology
Why MSR(10)
Dynamic resource
management
Static resource
management
Tributary transport
Next job
An Introduction to MSR Applications
•What is MSR?
•Why MSR?
•MSR Scope
•Multi-service capability
X.87 scope
IP
X.87 layer client
XP UNACK
Data Req.
X.87
Reference Point T1/T2
Ind.
RPR MAC client: X.87 layer
X.87
MAC
Ctrl
Req.
Ind.
MAC
Data
Req.
MSR
Reference Point G1/G2
Ind.
RPR MAC
GFP/HDLC
S[1]
S[0]
S[62
]
S[2]
S[8]
Client
RPR
LAPS
WEST
PHY
S[7]
GFP/HDLC
SDH/SONET
EAST
PHY
S[6]
LAPS
S[4]
Ringlet 1
RPR-MSR
Ringlet 0
protocol stack
S[5]
Layered Model (1)
IP
IP
IP
Multi-serv.
X.85
Ethernet
LLC
X.87
MSR
LAPS GFP/PPP
Ethernet
X.86 LAPS
SDH/SONET
IP over SDH
GFP
RPR
GFP/HDLC
LAPS
SDH/SONET
SDH/SONET
Ethernet over SDH/SONET
RPR-MSR
Layered Model (2)
IP
Other
X.87
Multi-service
MSR
802.3 MAC
802.3 PHY
802.3 MAC-MSR protocol stack
Layered model of Multi-service node
TCE(2)
GE
Ethernet
TCE(1)
MPLS
VLAN
CS & NM
L3 packet forwarding
Reference Point T1/T2
X.87 protocol
Reference Point G1/G2
RPR和IEEE 802.3MAC
MSR node
Agg
Agg
MSR node
Trib
Link+ADM
Trib
MSR node
MSR node
MSR node
Broadcast
MSR node
Agg.
MSR node
Agg.
Agg.
MSR node
MSR node
Agg.
MSR node
Agg.
MSR node
An Introduction to MSR Applications
•What is MSR?
•Why MSR?
•MSR Scope
•Multi-service capability
Differentiate RPR (1)
Features
RPR+MSR
RPR
Operation
mode
MAC+LLC
MAC
Supported
tributary
service
multi-congeneric-service
and multi-heterogeneousservice transport including
Ethernet, GE, FR, G.702
PDH circuit, Video signal,
voice-band signal, Digital
channel etc.
Class A/B/C ， but
does not support
multi-congenericservice
transport
within a station
Differentiate RPR (2)
Features
RPR+MSR
RPR
Multicast and Based on packet and Based on packet
broadcast
tributary
service,support
multi-congenericservice
within
a
station
Protection
1+1,1:1
and
1:N Station
based
standby,
support protection switch
multi-congenericservice
within
a
station
Differentiate RPR (3)
Features
Topology
RPR+MSR
RPR
Two-fiber
ring, Two-fiber ring
link, broadcast
Bridge across 802.1 Bridge or back- 802.1 Bridge
to-back
connection,
a ring
regeneration of service
tributary
improves
tributary QoS
Differentiate RPR (4)
Features
RPR+MSR
RPR
Link address
Global MAC address Global MAC address
or
local
MAC
address
Bandwidth
management
Support
-
Differentiate RPR (5)
Features
RPR+MAC
RPR
Support
-
Asymmetrical Support
service
-
Security
filtering
Differentiate RPR (6)
Features
RPR+MAC
Performance Performance
monitoring， monitoring and
Loopback test Loopback test
tributary
RPR
Loopback
for
Applications
Backbone
Backbone MSR
Access MSR
MAN/STM-64
Access MSR
Applications: POP Interconnect
RPR
2X2.5 Gbps
STM-16
2.5 Gbps
POS/EOS
RPR+MSR
2X2.5 Gbps
Further study in Q.C/17 (old Q.7/17)
• Maintenance of X.85/Y.1321 and X.86/Y.1323, Update and
extension of X.87/Y.1324;
• Progress draft Recommendation X.msr, including associated
Ethernet/Gigabit Ethernet/10G Ethernet aspects;
• Develop Requirements for MSDN, areas of study and
development include:
- Identification of market needs
- architectural considerations, for L2 data networks;
- multi-service multicast aspects;
- Ethernet UNI and NNI aspects.
• Enhance existing packet protocols or, if required, develop new
packet protocols to support the developed MSDN requirements,
including service mechanisms;
• Develop associated MIBs (Management Information Base) to
support item (iv);