Transcript 09Stuettgen

The ACTS / IthACI Project
EURESCOM AIMS Workshop
May 11, 1999
Heinrich J.Stüttgen
Computer & Communication Laboratories
NEC Europe Ltd, Heidelberg
stuttgen @ ccrle.nec.de
AIMS’99 Workshop
IthACI 1
Heidelberg, 11-12 May 1999
NEC
IP/ATM Environment at Project Start (1997)
• The wide-area ATM infrastructure provides the basis
for high performance Internet deployment
• various competing IP-Switching technologies appear
in the market place (Ipsilon, Tag, IPSOFACTO,...)
• the IETF starts the MPLS working group to define a
standard IP-Switching solution, initially focusing on
a solution for best-effort, pt-2-pt traffic
• Issues in the IP-World
–
–
–
–
scalable growth of the current Internet
provisioning of QoS in Internet services
the multicast nature of many Internet applications
Mobile host support
AIMS’99 Workshop
IthACI 2
Heidelberg, 11-12 May 1999
NEC
IthACI Objectives
• Set-up technology islands to integrate and evaluate
different existing & emerging IP-switching solutions
using Pan-European ATM WAN services
• Develop and demonstrate enhancements to the basic
IP-switching solutions for
–
–
–
–
multicast services
QoS provisioning
resource management
host mobility in a multicast environment
• Contributions to relevant standard organisation(s),
e.g. IETF MPLS WG
AIMS’99 Workshop
IthACI 3
Heidelberg, 11-12 May 1999
NEC
IthACI Scenario
IthACI Island
Technologies:
1. Blue Island:
CISCO Tag
switching
2. Green Island:
NEC IPSOFACTO
3. Red Island:
Alcatel based on
YALSA
AIMS’99 Workshop
IthACI 4
Heidelberg, 11-12 May 1999
NEC
IP Multicast in MPLS (I)
Why worry about IP Multicast in IP-Switching ?
• Multicast flows are usually long-lived and high bandwidth
“flows”
• switching MC flows eliminates a potential L3 congestion
point as MC flows are UDP and don’t have L4 flow control
• Easy detection of multicast “flows”
– Class D addresses, explicit signaling e.g. PIM-SM
• Eliminates MARS/MCS for IP/ATM integration
– No need for complex multicast emulation protocols.
– Support of native IP multicast.
• In 1998 IETF MPLS WG did not address MC =>
opportunity for IthACI to contribute
AIMS’99 Workshop
IthACI 5
Heidelberg, 11-12 May 1999
NEC
IP Multicast in MPLS (II)
How to set-up multicast LSP (shortcuts) ?
• pt-2-mpt ATM VCC
• traffic-driven or control-driven (explicit signalling)
• LDP MC Extension Problems:
– disjoint label space
• no 2 LSRs assign the same label on a common subnet.
– arbitration of label assignment within a downstream MC
group (on a shared media subnet)
• who decides within a group which label is to be used?
– LDP is TCP-based, TCP is not “multicastable”
shared media network
LSR
down1
LSR
upstr
Label
Request(s)
AIMS’99 Workshop
IthACI 6
Heidelberg, 11-12 May 1999
1 Label Mapping ?
LSR
down 2
NEC
IP Multicast in MPLS (III)
IthACI development and experiments
• PIM-SM as common routing protocol.
• 3 different architectures:
– traffic-driven with dedicated label protocol (Alcatel).
– traffic-driven with implicit label assignment and some
LDP extensions (NEC).
• NEC and Alcatel to be interoperable.
– Control-driven with PIM piggybacking (Cisco)
• Joint proposals at the IETF MPLS Working Group
AIMS’99 Workshop
IthACI 7
Heidelberg, 11-12 May 1999
NEC
QoS-Provisioning in IP Switching
• Observation
– IP-Switching is build around flow-detection of IP flows without
using explicit signaling (except label distribution)
• Questions
– Which flows require QoS support at all?
– How to determine QoS requirements of a new flow?
– If we can detect the QoS requirements of a new flow,
how can we then assure/allocate it for the flow?
• Green Island (IPSOFACTO-) Approach
– QoS detection for multimedia streams, i.e. RTP-flows
– use per flow priority for RTP flows
– for aggregated flows
• integration topology driven (MPLS) label switching
• collect traffic info in “FlowMib” by monitoring and RTP detect.
• evaluate use of FlowMib for resource (bandwidth) management
AIMS’99 Workshop
IthACI 8
Heidelberg, 11-12 May 1999
NEC
QoS Enhancements with RTP
Prerequisite:
– Identification of RTP flows
– Shortcut each RTP flow individually,
no aggregation of RTP flows
Advantages/Achievements:
– Provisioning of specific “Quality of Service” or just “Class of
Service”
– Assignment of priority according to RTP payload type
– No additional signaling, no signaling overhead
– Relatively simple scheme to provide “Better than Best-Effort
Service”
AIMS’99 Workshop
IthACI 9
Heidelberg, 11-12 May 1999
NEC
RTP Flow Detection
IP routing
RTP specific
packet handling
control flow
IP packet flow
IPSOFACTO
• QoS detection
• CoS mapping
UDP specific
packet handling
TCP specific
packet handling
Shortcut
establishment
Packet
analyzer
From ATM driver
AIMS’99 Workshop
IthACI 10
Heidelberg, 11-12 May 1999
To ATM driver
NEC
RTP “QoS” Information
• RTP profile
– problem: application context not signaled through RTP
– for QoS detection we assume standard profile as defined in
[RFC1890] “RTP Profile for Audio and Video Conferences with
Minimal Control”
• RTP payload type (PT)
– RTP header contains PT field (7 bits)
– PT statically or dynamically defined
– static PTs in [RFC1890] give information about
•
•
•
•
encoding scheme
media (audio/video)
clock rates
number of audio channels
AIMS’99 Workshop
IthACI 11
Heidelberg, 11-12 May 1999
NEC
RTP Header Validity Check
•
•
•
•
very simple
very easy
very fast
on the fly checking of a few fields in the
(assumed) RTP header:
– RTP version
– RTP payload type
– consistent packet length
• “weak” test - therefore it may fail
AIMS’99 Workshop
IthACI 12
Heidelberg, 11-12 May 1999
NEC
QoS & Resource Mgmt. in the Green Island
QoS
flow detection
“RTP QoS analysis”
for RFC1890 profile
VC-QoS allocation
(priority in GSMPv1)
Flow MIB
• resource (bandwidth) management
• accounting
path information
for “aggregated flows”
per flow traffic
statistics
Bandwidth Allocation
Dynamic Bandwidth
Adoption for RTP
Flows
AIMS’99 Workshop
IthACI 13
Heidelberg, 11-12 May 1999
NEC
QoS and RM - the enCoS Framework
• enCoS <---> explicit network Class of Service
• Traffic streams fall into enCoSs
• enCoS is a set of QoS Parameters and associated
Targets
–
–
–
–
–
bandwidth -----> miminum, maximum
delay -----> maximum tolerance
assurance level (guaranteed, statistical)
availability level (e.g. 95%)
others (protocol, priority, etc.)
• Parameters and Targets can be determined
– by the needs of existing services
– according to the business objectives of ISPs
• enCoS parameters MUST be managed by the network
AIMS’99 Workshop
IthACI 14
Heidelberg, 11-12 May 1999
NEC
enCoS Network Operation
Network sees enCoS streams (not individual flows)
IP
Packets
Packets of
enCoS
streams
enCoS
streams
‘engineered’ enCoS routes to meet their QoS requirements
AIMS’99 Workshop
IthACI 15
Heidelberg, 11-12 May 1999
NEC
Client and
Serve
r for IP Roaming
Mobile
IP-based
VPN
IP Subnet
MN sends reply datagram to CN by means of
standard IP routing mechanisms.
Foreign Network
CN
CN sends datagram
directed to the standard
IP address of the MN.
HA
Datagram arrives on
home network via
standard IP routing.
Datagram is intercepted
by the HA.
MN
FA
FA de-tunnels datagram
and delivers it to the MN.
HA tunnels datagram and
sends it to the FA.
Home Network
AIMS’99 Workshop
IthACI 16
Heidelberg, 11-12 May 1999
NEC
Summary
• IthACI is a 3rd call ACTS project (98-99), focusing
• on the evaluation and demonstration of different IP
switching technologies for ATM-based networks
– applicability & interoperability
• and the enhancements of the evolving MPLS
standard in the areas of
– Multicast, Quality of Service, Resource Management,
Mobility
– MPLS MC discussion in the IETF MPLS WG is driven by
Alcatel, Cisco and NEC
• demonstrations of the enhanced islands (incl. MC
interoperability) expected for 3rd quarter
AIMS’99 Workshop
IthACI 17
Heidelberg, 11-12 May 1999
NEC