One document matched: draft-polk-ieprep-flow-model-considerations-00.txt
Internet Engineering Task Force James M. Polk
Internet Draft Cisco Systems
Expiration: July 16th, 2003
File: draft-polk-ieprep-flow-model-considerations-00.txt
Considerations for IEPREP Related
Protocol Packet Flow Models
January 16th, 2003
Status of this Document
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Abstract
This document diagrams the packet flows - both signaling and data - of
Internet Emergency Preparedness (IEPREP) related protocols. This document
serves as a point of reference for the WG when discussing if (and
which) QoS mechanisms should be employed for each individual (application)
protocol packet flow to function properly during congestion events from IP
source to IP destination.
Polk IEPREP Protocol Packet Flow Considerations Page 1
Internet Draft Jan 16th, 2003
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . 3
2.0 Why Do Packet Paths Matter? . . . . . . . . . . . . . . . . . . . 3
3.0 Control and Data Plane Diagrams . . . . . . . . . . . . . . . . . 4
3.1 In-Band Point-to-Point Communications . . . . . . . . . . . . . . 4
3.2 In-Band Signaling Via a Server . . . . . . . . . . . . . . . . . . 5
3.3 Out-of-Band Signaling . . . . . . . . . . . . . . . . . . . . . . 6
4.0 Security Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 6
6.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
7.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.0 Authors Information . . . . . . . . . . . . . . . . . . . . . . . 8
1.0 Introduction
This document diagrams the packet flows - both signaling and data - of
Internet Emergency Preparedness (IEPREP) related protocols. This document
should be seen as a point of reference for the WG when discussing if (and
which) QoS mechanisms should be employed for each individual (application)
protocol packet flow to function properly during congestion events from IP
source to IP destination.
The models shown within the document will focus (and list) those protocols
of interest to the Internet Emergency Preparedness (IEPREP) Working Group.
Of particular interest here is the classification of protocols that have
their signaling packets travel along the same path as the data packets,
and which protocols do not share the data path with their signaling
packets.
This document will focus on the concept that in most IETF protocols there
are one or two control planes and one data plane.
1.1 Motivation
This document clarifies paths taken by signaling and data packets for
typical IETF protocols. These concepts will help facilitate IEPREP
discussions on ensuring applications perform adequately during congestive
events.
Polk IEPREP Protocol Packet Flow Considerations Page 2
Internet Draft Jan 16th, 2003
1.2 Terms and Definitions
The following are pointed out for clarity:
Control Plane - See "In-Band Signaling" and "Out-of-Band Signaling"
Data Plane - the data packet (media, text, MIME body) path between
an IP source and one or more endpoints
Intermediary Server - Any server that is the destination of control
information from the IP source. These packets can either be
for the server itself, or for further forwarding toward the
intended destination possibly manipulating the packet(s) in
transit
In-Band Signaling - the control plane packets traversing the same
path as the data plane between endpoints (same source IP
address and port number, as well as the same destination IP
address and port number)
Out-of-Band Signaling - the control plane taking a different path
than the data path or the In-Band control plane (either the
source and destination IP addresses are different between the
control packets and data packets, or the port numbers used
between the same source and destination IP addresses is
different)
2.0 Why Do Packet Paths Matter?
Most IETF communications use the following simple model:
Sender ========> Router(s) ========> Receiver
Figure 1. Direct IP Communications
But many IP communications use this model (or a variant of it):
Intermediate Server
/ \
Out-of-Band / \ Out-of-Band
Control plane A / \ Control plane B
/ Data plane \
============================>
Sender Receiver
++++++++++++++++++++++++++++>
In-Band Control plane
Figure 2. IP Communications using Intermediate Server
Polk IEPREP Protocol Packet Flow Considerations Page 3
Internet Draft Jan 16th, 2003
The data plane can be within the signaling protocol (in the case of
Instant Messaging), or it can be a completely different protocol (i.e. RTP
for Voice or Video [1] or SMTP [2]). In some cases, there is no In-Band
control plane. In other cases, there is no out-of-band control plane. Some
protocols use both Out-of-Band control planes (A & B) in Figure 2
separately (such as with MEGACO/H.248[3] or H.323[4]).
An additional aspect of this model in Figure 2 above is that there will
likely be more than one intermediate server involved in most protocols
that communicate through any intermediate server. Most likely there is one
in the source IP device's domain, and there is also one in the destination
IP device's domain. There may or may not be any intermediate servers in
the ISP(s) between these two domains; sometimes there might be several
servers between the source and destination domains.
Because there can be up to 3 separate communications planes, with up to 2
different packet paths for a communications transfer, it is important to
understand which protocols transmit their packets on which path. The rest
of this document will provide these various packet path models for IEPREP
related protocols.
Keep in mind that the "Receiver" in many of these diagrams is either (or
both) a server and/or a user device.
Also note that this document doesn't cover an exhaustive IETF protocols
list, each categorized, but attempts to include those that are of interest
to the IEPREP effort.
3.0 Control and Data Plane Diagrams
Figure 1 (above) showed the simplest of IP communication between source
and destination, but this model requires the source to know the IP address
of the destination, for that source to use a protocol that requires no
intermediate servers, and that protocol to have all necessary signaling
and data traverse point to point.
3.1 In-Band Point-to-Point Communications
This model is true only if the communication is as in the previous
paragraph: one protocol (with one port number) and one path though a
network. Figure 3 below shows this in diagram form:
Polk IEPREP Protocol Packet Flow Considerations Page 4
Internet Draft Jan 16th, 2003
--------> --------> -------->
Sender Router1 Router2 Receiver
========> ========> ========>
Legend: ----> In-Band Control plane (signaling)
====> Data plane (media/text/file)
Figure 3. In-Band Signaling example
Protocols that use this model for IP communications are:
- H.323 (without a Gatekeeper only)[4]
- Telnet [5]
- SIP (when the UAC knows the IP address of the UAS)[6]
- HTTP [7]
- POP3 [8]
- IMAP [9]
The data plane in these protocols is set-up by the signaling (control)
plane between endpoints.
3.2 In-Band Signaling Via a Server
A variation on the In-Band Model shown in Figure 3 (above) is the one in
Figure 4 in which all communications traverse an Intermediate Server(s).
Here the signaling and data are contained with the same protocol that hops
through a server(s) on its path towards the destination IP device.
In Figure 4 below, the placement of one or more routers doesn't directly
affect the path of the packets between the Sender to the Server and on to
the Receiver, therefore none are shown here to make the diagram cleaner.
--------------> ------------->
Sender Intermediary Server Receiver
==============> =============>
Legend: ----> In-Band Control plane (signaling)
====> Data (media/text/file) plane
Figure 4. In-Band Signaling example
Signaling protocol that uses this model for IP communications is:
- SIP (when used for instant messaging[10])
Polk IEPREP Protocol Packet Flow Considerations Page 5
Internet Draft Jan 16th, 2003
The data plane generally occurs within the signaling packets as MIME
bodies or text.
3.3 Out-of-Band Signaling
Out-of-Band control is the case where a signaling protocol (likely)
establishes the data plane via some intermediate server or servers (see
Figure 5). In this example, the data packets are not transmitted to or
through the server (towards the ultimate receiver). The signaling path
from the sender to the server is not the same path as the data plane from
the sender to the receiver (which is direct in this example). Here each
path could be considered for different treatment and handling.
Intermediary Server
^ .
. .
............. .............>
Sender Router1 Router2 Receiver
========> ========> ========>
Legend: ....> Out-of-Band Control plane (signaling)
====> Data (media/text/file) plane
Figure 5. Out-of-Band Signaling example
Protocols that use this model for IP communications are:
- SIP (for Voice and Video when the UAC does not know the IP
address of the UAS, thus requiring a Proxy Server [6])
- FTP [11]
H.323 [4] and MEGACO/H.248 [3] are not categorized here because these
protocols use two independent control planes between the Gatekeeper or
Media Gateway Controller and each endpoint or termination (see Figure 2 -
control planes A & B).
As an example of the data plane in Figure 5 above with SIP signaling, the
data protocol is RTP (either Voice or Video [1]).
4.0 Security Considerations
This document merely discusses the modeling differences of various IETF
protocols which control the communications signal between a source and
(one or more) destination(s), therefore there are no special security
considerations.
Polk IEPREP Protocol Packet Flow Considerations Page 6
Internet Draft Jan 16th, 2003
5.0 IANA Considerations
There are no IANA considerations within this document
6.0 Acknowledgements
To Scott Bradner, Kimberly King, and Henning Schulzrinne for their
comments and suggestions
7.0 References
[1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ôRTP: A
Transport Protocol for Real-Time Applicationsö, RFC 1889, January
1996
[2] J. Klensin, "Simple Mail Transfer Protocol, RFC 2821, April 2001
[3] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J.
Segers, ôMegaco Protocol Version 1.0ö, RFC 3015, November 2000.
[4] ITU-T H.323v2 Recommendation, "Packet-Based Multimedia
Communications System", 1996
[5] J. Postel, J. Reynolds, "Telnet Protocol Specification", RFC 854,
May 1983
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[7] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., Masinter, P.
Leach, T. Berners-Lee, " Hypertext Transfer Protocol - HTTP/1.1",
RFC 2616, June 1999
[8] J. Myers, M. Rose, "Post Office Protocol - version 3", RFC 1939,
May 1996
[9] M. Crispin, "Internet Message Access Protocol - Version 4 rev1",
RFC 2060, Dec 1996
[10] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D.
Gurle, " Session Initiation Protocol (SIP) Extension for Instant
Messaging", RFC 3428, December 2002
[11] J. Postel, J. Reynolds, "File Transfer Protocol", RFC 959, Oct
1985
Polk IEPREP Protocol Packet Flow Considerations Page 7
Internet Draft Jan 16th, 2003
8.0 Authors Information
James M. Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082 USA
jmpolk@cisco.com
"Copyright (C) The Internet Society (2002).
All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
The Expiration date for this Internet Draft is:
July 16th, 2003
Polk IEPREP Protocol Packet Flow Considerations Page 8
| PAFTECH AB 2003-2026 | 2026-04-22 13:31:43 |