Transcript Diapositive 1

CCSDS-SOIS Meeting - ESTEC - April 21, 2004
Jean-Pierre Courtiat
LAAS-CNRS
Toulouse – France
Email: [email protected]
Estec meeting – 21/4/04
•
Several contradictory statements
•
Lack of documentation on SNDCP and TCONS
•
Need for identifying and specifying the basic convergence layers
•
Identification of the basic communication functions and their distribution
among the different layers without undesired redundancy
•
Negotiation mechanisms for selecting the most adequate transport
•
Precise definition of the basic communication services (Transport and DL),
independent of the selected protocols
•
Precise mapping between the different layers
General Overview of the Communication Architecture
Some Issues Related to the Communication Architecture
•
Decomposition into subnets
•
Reliability and ordering
•
Number of independent data streams between endpoints
•
QoS requirements and QoS mapping between layers
•
Need for another convergence layer ?
•
Error recovery, flow control, congestion control
•
Open questions
•
Formal methods and models for the Specification of protocols and
services
Decomposition into (IP) subnets
•
Classical Implication of the decomposition into (IP) subnets
– Only one subnet
- The communication service may be managed at the Data Link layer
– More than one subnet
- The communication service may be managed at the Data Link layer if both peers are
connected to the same subnet
- The communication service must be implemented at the Transport layer if both peers are
connected to a different subnet
•
Related questions
– Should each specific bus be associated with a specific subnet or is it possible to
foresee bridging two different busses (one subnet)
- Potential problems introduced by bridging
– Transport layer is not required in Paragraph 6.2 of CCSDS 830.0-G-0.4
•
No documentation on the Sub-Network Dependent Convergence Sub-layer and on
TCONS
Reliability , Ordering and Bounded Delay (QoS)
•
Assuming an unreliable underlying service together and a retransmissionbased error correction mechanism, it is possible to achieve
– Reliability + Ordering
– Ordering + Bounded Delay
– BUT, Reliability + Ordering + Bounded Delay are not possible together
•
Under the same assumptions, isochronous communication is only
possible if bounded delay is ensured by the communication service
– In this case, a protocol like RTP may be required (for managing the jitter
compensation buffer)
•
The probability of packet losses may however be reduced through
adequate resource provisioning and queuing mechanisms (at layer 3)
– And probably at layer 2 (depending on the bus)
– But packet loss may also be the consequence of transmission errors (CRC)
•
Different solutions are being proposed by IETF for the Transport layer
– TCP/UDP, DCCP, SCTP
•
What about the Sub-Network Dependent Convergence Sub-Layer ?
New Generation Transport Services and Protocols
•
The classical approach
– TCP
– UDP (often in association with RTP/RTCP for multimedia applications)
•
New transport protocols being studied at IETF
– SCTP (Stream Control Transmission Protocol) (RFC 2960, RFC 3286)
- Reliable transport protocol, unicast and session oriented
- SCTP session established between two end systems
- Message oriented protocol, multi-streams service
- Full ordered intra-stream service, full un-ordered inter-stream service
- Flow and congestion control at the level of the association
– DCCP (Datagram Congestion Control Protocol) (Internet drafts)
- Non reliable transport service regulated by a congestion control mechanism
- Efficiency of UDP and congestion control of TCP
Comparing TCP and UDP
Reliability
1
TCP
Reliable
Ordered
0
0
1
Ordering
UDP
Unreliable
Unordered
Comparing DCCP and SCTP
DCCP
SCTP
.
.
.
.
.
.
Positioning TCP, UDP, DCCP and SCTP
Reliability
1
SCTP
TCP
0
UDP 0
1
Ordering
DCCP
Number of Independent Data Streams between Endpoints
•
Endpoints at the level of the Transport layer
– Endpoint = (IP @, Port number)
– With TCP and DCCP only one data stream between endpoints
– With SCTP multiple data streams are possible between two endpoints
– No notion of stream for UDP
•
Endpoints at the level of the Data Link layer
– Endpoint = MAC address
– Only one stream between two endpoints
- Only one application is running between two machines
- If there is more than one application running between two machines, then a
Transport layer is required
•
From an architecture point of view, the presence of the Transport layer
does not only depend on the number of subnets
How to express QoS Requirements?
•
•
•
Option 1: explicitly by each application
– QoS parameters are defined through Transport Service Primitives
– Applications specify explicitly their QoS requirements
– Case of a connection-oriented transport
- Negotiation & reservation mechanisms carried out at connection setup
- Similar to the ATM approach for QoS management
– Case of a connection-less transport
- Explicit marking of the packets
Option 2: implicitly by each application
– Definition of predefined classes of services for the Connection-oriented
Transport Service (Emergency, Expedited, Best Effort)
Option 3: implicitly through a QoS policy manager
– Data streams are classified
- 5-tupe at the transport layer: (transport protocol, S IP @, D IP @, S port, D port)
– Policy rules for associating packets with different QoS classes
- Marking of packets (or frames)
– Similar to the DiffServ approach for QoS management (also 802.1 P)
– No negotiation, no reservation mechanism but adequate resource
provisioning for each QoS class and adequate scheduling mechanisms
How to express QoS Requirements? (cont’d)
• Adaptation of theses approaches to the Data Link layer interface
– Also related to the available Bus Allocation mechanism
• Which option(s) are preferable from an architecture point of view ?
Some QoS Requirements … ATM-like model …
QoS Parameters
Service Categories
CBR VBRrt VBRnrt ABR
M
SCR
MBS
MFS
Peak Cell Rate
Minimal Cell Rate
Sustainable Cell Rate
Maximum Burst Size
Maximum Frame Size
CTD
CDV
CLR
Cell Transfer Delay
Cell Delay Variation
Cell Loss Ratio
D
D
D
PCR
MCR
M
M
M
M
GFR
UBR
M
M
M
M
M
M
M
M
D
D
D
M: Mandatory (mandatory in setup) D: Default
D
D
D
D
Some QoS Requirements … IEEE 802.1-like model …
Value Type of traffic
P
R
I
O
R
I
T
Y
1
Background (BK)
0
Best effort (BE)
2
-------
Signification
Number of queues
1
2
3 4 5
Bulk traffic non
urgent
Current LAN traffic BE
Spare
6
7
BK BK BK BK
BE BE BE BE BE BE
CEO’s best effort
3
Excellent effort (EE)
EE EE
4
Important appliControlled load (CL) cations with CAC
5
Video (VI)
Delay < 100ms
6
Voice (VO)
Delay < 10ms
VO VO VO VO VO VO
7
Network control (NC) Administration
NC
CL CL CL CL CL
VI VI VI
QoS Requirements Mappings between Layers ?
•
Mapping 1: Transport Service QoS Parameters => Transport Protocol
– Possible negotiation of some end-to-end mechanisms
•
Mapping 2: Transport Protocol => Network Service (and Protocol)
– Packet marking
– Other required functions ?
- Shaping and Policing, Scheduling
•
Mapping 3: Network Protocol => Sub-Network Dependent Convergence
Protocol
– Mapping of the packets on pre-defined classes of services
– See the SNDCP specification ?
•
Mapping 4: Sub-Network Dependent Convergence Protocol => Bus
mechanism
Is there a Need for Another Convergence layer ?
•
Communication Service Convergence Layer
– Below the current application layer
– A unique communication service specification in charge of managing two possible
protocol stacks and performing the adequate mappings without possibly adding any
new header (?)
- Application layer on top of a full communication stack
- Application layer on top of the SNDCP (Data Link layer)
•
The decision to use a Transport layer does not only depend on the number of subnetworks in the system
– Are the two communication endpoints on the same subnet (same bus or bridged
busses)
– Are there only one or several communications flows between the two endpoints ?
•
The purpose of this convergence layer was probably played by the ACSE
(Association Control Service Element) in the original and complete OSI model
– Global application communication interface to the Session, Presentation and
Transport layers
Error recovery
•
Type of errors
– Data link transmission errors
– Losses due to the congestion of intermediate devices
- At the data link layer (congestion in switches) (within the same subnet)
- At the network layer (congestion in routers) (between subnets)
- Avoided through adequate congestion control
– Losses due to the overflow of the receiving endpoint
- Avoided through adequate flow control
– Routing errors (between subnets)
•
Case of a full stack (Application, Transport, Network, Data Link, Physical)
– Error recovery if any at the Transport layer (for instance TCP)
- No error recovery with UDP (UDP is not reliable)
– Normally no error recovery at the data link layer in this configuration
•
Case of a simplified stack (Application, Data Link, Physical))
– Error recovery if any at the Data Link (for instance LLC type 2, type 3)
- No error recovery with LLC Type 1
Flow control
•
Basic mechanism: Sliding window mechanism
•
Purpose: to avoid overflow at the receiving endpoint
•
Case of a full stack (Application, Transport, Network, Data Link, Physical)
– Flow control if any at the Transport layer (for instance TCP)
- No flow control with UDP
– Normally no flow control at the data link layer in this configuration
•
Case of a simplified stack (Application, Data Link, Physical))
– Flow control if any at the Data Link (for instance LLC type 2, type 3)
- No flow control with LLC Type 1
Congestion control
•
Different mechanisms
•
To avoid congestion in an intermediate device
– Layer 2 switch
– Layer 3 router
•
Congestion control at the Transport layer
– Slow start mechanism of TCP
– Congestion control mechanisms for UDP
- For instance TFRC (TCP Friendly Rate Control)
•
Congestion control at the Data Link layer
– For instance, 802.3 x for Switched Ethernet
– Specific bus allocation mechanisms
Open questions
•
Positioning of TCONS
– Data Link or Transport
•
Specification of TCONS
•
Specification of SNDCP
•
Expression of the QoS requirements
•
Presence of another convergence layer
•
Multicast
•
…
Position statements
•
OMG’s UML
– A notation, not a methodology
– The metamodel is not a formal semantics
– UML 2.0 does not supersede SDL in terms of communication
semantics and real-time mechanism description
•
Principles of protocol design
– An incremental process
– Based on stepwise refinement
- You start from a highly abstract model and progressively drop out
restrictive hypothesis on the system and its environment
– Early detection of design errors is of prime importance
- A priori validation combines simulation and verification
•
Rationale behind the proposed methodology
– Objective: model-driven validation of communication architectures
– The best of UML 2.0 and adds-in from the TURTLE profile
– Reuse of analysis and architectural patterns
- Protocol engineering community
Position in the software life cycle
Modeling
A priori validation
(Simulation
Verification)
Analysis
Design
Coding
Integration
Validation
Maintenance
Usage of UML 2.0 in Protocol Design
Interaction diagram
Use case
m1
m2
:
<<usecase>>
:
<<usecase>>
:
<<include>>
<<usecase>>
Class diagram
State diagram
Class1
Class3
Class2
Class4
Class5
Sequence diagram
C
p3:Class3
p5:Class5
Formal Description and Validation of Communication
Protocols and Architectures
• Formal description
– A notation with a formally defined syntax and semantics
• Advantages in using a formal method
– No ambiguity in the description
- Exchange of documents within a project
– Underlying mathematical model
- Validation of properties (by simulation or exhaustive verification)
- Derivation of test sequences
- Design of self-checking system (Observer concept)
- Derivation of implementation prototypes
• Protocol / Service
Formal definition and validation of communication
protocols and architectures (cont’d)
• Different formal models have been proposed …
– Different communities
– Different levels of maturity: design methods, tools, practical
experience, …
– Different levels of abstraction: executable versus non executable
• Experience of the OLC research group
– Models: Petri nets, communicating FSMs, process algebra
– Standardized formal description techniques: SDL, Estelle, LOTOS
– And also UML (Unified Modeling Language) of OMG
- Use cases diagrams, sequence diagrams, class diagrams,
activity and statechart diagrams, …
– Tools, design methods and applications
• Increasing importance of time constraints
– Time Petri Nets, Real-Time LOTOS, …
– TINA & RTL
Formal definition and validation of communication
protocols and architectures (cont’d)
• Formal validation
– Simulation versus exhaustive verification
- Enumeration of all global states from the initial state
– Properties
- General properties: absence of deadlocks, of unspecified
receptions, …
- Specific safety properties
- Specific liveness properties
– Property verification
- Obtention of the Global Reachability Graph
- Minimization of the GRG modulo some behavioral equivalences
- Model checking, observers, …
- Sometimes on the fly …
• State Space Explosion
– Concurrency, Data variables, Dense time
FPTP (Fully Programmable Transport Protocol)
a new multimedia Transport Protocol
Reliability
1
SCTP
TCP
Partial
Reliability
FPTP
DCCP
0
UDP
1
0
Partial Order
Ordering
Global Communication Architecture &
Protocols for new QoS services over IPv6
- Generalize UDP - TCP (compatibility)
- Use IPv6 AS the Basic Protocol
- Define protocols for
Multimedia and Multicast
- Use Remote Loading and Execution
(Active Node based support)
LAAS-CNRS (F), Eriksson Telebit (DK), Thomson Detexis (F), Telekom Austria (A),
Alcatel Space (F), GMD (D), Uni. Lancaster (UK), Uni. Carlos III (SP), Uni. Paris 6 (F)