Transport Area Working Group J. Adams
Internet-Draft Anagran, Inc
Intended status: Informational J. Joung
Expires: August 2, 2008 J. Song ETRI
June 24, 2008
Progress and future development of Flow State Aware standards, and a
proposal for alerting nodes or end-systems on data related to a flow
draft-adams-tsvwg-flow-signalling-codepoint-00
Status of this Memo
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
Adams, et al. Expires August 2, 2008 [Page 1]
Internet-Draft Flow Signalling Codepoint June 2008
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79."
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.
This Internet-Draft will expire on August 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Adams, et al. Expires August 2, 2008 [Page 2]
Internet-Draft Flow Signalling Codepoint June 2008
Abstract
This document describes the work in progress on Flow State Aware
standards activity in the ITU and proposes a new type of control packet
to be identified that can alert downstream or upstream nodes on data
related to an individual flow.
Adams, et al. Expires August 2, 2008 [Page 3]
Internet-Draft Flow Signalling Codepoint June 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Issue . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security considerations . . . . . . . . . . . . . . . . . . . 8
6. Informative References . . . . . . . . . . . . . . . . . . . .8
Adams, et al. Expires August 2, 2008 [Page 4]
Internet-Draft Flow Signalling Codepoint June 2008
1. Introduction
This contribution calls for a new type of control packet to be
identifiable that will allow rate, security or other data related to an
individual flow to be passed downstream and alerted to nodes and/ or the
receiving end system, where such entities may want to manage flows based
on this data, or passed upstream towards a source or Service Provider.
2. Background
Many ideas have converged under the general heading of Flow State Aware
QoS control. The published papers on this topic date back to the late
90's, especially the early concepts of Flow Aware Networking from France
Telecom [1] with no signalling and on the fly identification of flows in
progress. It had admission control for both elastic and streamed flows,
depending on the value of a parameter recording measured spare capacity
of a network link. It was characterised by bufferless multiplexing and
QoS routing, avoiding congested links and applied per flow.
The direction of the standards work in the ITU has, however, moved
beyond these initial concepts. It is developing standards that extend the
range of FSA-based QoS controls through explicit signalling with the
inclusion of parameters indicating the treatment required. The first
phase of standards work reached consent on:
(a) A new transport service that provides, in effect, admission
control in the form of the state assigned to a flow. Flows are
allowed to proceed (usually) but the state determines the
vulnerability to discard.
(b) A basis for developing requirements for FSA.
In Q4/13 of the ITU, the second phase of work (on Recommendation Y.2121)
includes in-band signalling protocol and procedure for establishing the
fastest available rate that could be offered to a flow. Y.2121 also
allowed for the option of an out-of-band signalling model as an optional
alternative to the in-band approach, although with expected differences
in the frequency of rate permissions that could be assigned to an
elastic flow. Y.2121 also introduced requirements for FSA QoS controls
applied to flow aggregates. The ITU sent the IETF a liaison attaching
Y.2121 in January 2008[2], thus Y.2121 is available to the IETF.
Adams, et al. Expires August 2, 2008 [Page 5]
Internet-Draft Flow Signalling Codepoint June 2008
To answer a question about the expected benefit of all this activity:
* One benefit is that Y.2121 provides the basis for developing an
Intelligent Edge supporting end systems that do not have in-
built FSA capability and merely launch new flows. The signalling
path may be limited to Edge to Edge co-ordination to manage flows
with statically-assigned preference priorities. Additionally, rate
control can be applied per flow to manage any link with high delay
or loss which makes TCP inefficient.
* A specific example is to manage the limited use over a bad
link like a satellite. The signalling is terminated at both
ends of the bad link and is never seen by the network
elsewhere. Current implementations of this have shown 50:1
improvement over satellites using FSA technology.
Network----Proxy--FSA Device---Satellite---FSA device--Proxy-----Network
(No FSA (No FSA
signalling) signalling)
The current work in the ITU is in Q5/11. Whilst many of the concepts
above can be applied end-to-end, the focus of the ITU work is only on
service access scenarios.
The basic aim is the application of FSA QoS in the limited capacity
pathway downstream from a service point of access towards an end system
or upstream from an end system towards a service point of access. Such a
pathway may cross through the core of an IP network, but any FSA signals
would only be visible at FSA edge functions and FSA source/ receiver
functions at either end (or both ends) of the access pathway.
FSA signals are deleted by FSA Edge functions or FSA source/ receiver
functions so that they do not travel beyond the access pathway. This
will require all FSA signal initiated at an FSA Edge (acting as the
virtual signal source) to be marked so that response signals associated
with such flows are deleted at the same Edge (even if this is separated
into different sending and receiving physical units).
3. Issue
This contribution would argue that the current ITU work is concerned
with scenarios and control protocols that do not affect IETF protocols,
because of the restrictions placed on the scope of the work. However,
it is recognised that there are significant advantages to extending the
applicability of FSA controls to cases where (for example) a content
source is anywhere on the internet and user space cannot convey
information to or from the network as in encrypted IPv6.
Adams, et al. Expires August 2, 2008 [Page 6]
Internet-Draft Flow Signalling Codepoint June 2008
When end systems are participating in FSA signalling, the full richness
of FSA capabilities can be invoked. Available rate signalling could be
used to determine an optimal file transfer rate. Preference priorities
can be invoked dynamically. Feedback can be given to applications that
allow them to adjust to make best use of the available capacity.
This contribution captures a more general requirement that follows from
this (and is a general requirement in the sense that the utllity is not
restricted to FSA). It is a requirement for a new type of control packet
to be identifiable that would facilitate:
* The inclusion of new information obtained from (typically, but not
necessarily) an edge function, providing rate or security or other
data related to an individual flow.
* The alerting of any of the following that new data is available:
o the receiving end system;
o downstream nodes with links that are affected by that flow;
o the source;
o an upstream function (for example a function that creates a
copy of this packet and forwards it to a Service Provider
function)
Whilst not providing an exhaustive list of the uses of such a new
control packet, the following give some example uses, of which (a) and
(b) are outside the scope of FSA signalling, but may be of interest to
the IETF community.
(a) A reporting function giving, for example, delivered
instantaneous rate information relating to a selected flow,
forwarding this data towards a source or an upstream Service
Provider function, or both (allowing end-users to have some
selection of flows they wish to monitor, as well as Service
Providers). As stated above, this may be of use outside a purely
FSA context.
(b) A reporting function giving the instantaneous status that a
flow is in competition with one or more flows that have an
overriding priority. Again this information may be forwarded
towards a source or Service Provider. Again, as stated above,
this may be of use outside a purely FSA context.
(c) FSA in-band signals that are forwarded from or towards any
end-point on the Internet.
4. Proposal
There has been complete agreement at the ITU to take Y.2121 through as
a consented Recommendation. This same cross-company support is
continuing as part of the official and agreed workplan of Q 5/11.
Adams, et al. Expires August 2, 2008 [Page 7]
Internet-Draft Flow Signalling Codepoint June 2008
It has been useful that new ideas have been allowed to develop and
become captured in this process, for example from ETRI in Korea who were
co-editors of Y.2121.
Nevertheless, this contribution invites comment on a proposal that would
rapidly help the advancement of the work and where the help of the IETF
would be invaluable. That the IETF Transport Area endorses the
identification of new IPv6 control packets, supporting the requirement
outlined in section 3 of this contribution. Through the IETF working to
assign a suitable codepoint for this purpose, our belief is that this
would permit per-flow in-band signalling whilst ensuring
interoperability with IETF protocols.
As a further clarification, encryption should not obscure the
identification of such control packets at intermediate nodes in the
network. Also, systems that do not recognize the codepoint should pass
the packet forward ignoring the code point.
5. Security considerations
An eavesdropper, which can monitor the packets that correspond to the
connection to be attacked could learn the IP addresses and port
numbers in use (and also sequence numbers etc.) and easily attack the
connection. In such situations, proper authentication mechanisms such
as those described in [RFC4301] should be used.
Flow State Aware parameters must be protected against unauthorized
modification while in transit. Furthermore, flow State Aware parameter
requests must be protected against replay attacks, in conjunction with
data integrity protection binding a set of Flow State Aware parameters
to a specific flow.
FSA nodes within a domain may authenticate to peer FSA nodes within the
domain. FSA nodes communicating as peers across a domain boundary
should authenticate with each other.
6. Informative References
[1] Jim Roberts, Flow Aware Networking for effective quality of
service control, IMA Workshop on Scaling, October 1999.
[2] ITU Liaison Statement to the IETF, Jan 2008, attachment Y.2121.
Adams, et al. Expires August 2, 2008 [Page 8]
Internet-Draft Flow Signalling Codepoint June 2008
Authors' Addresses
Dr John Adams
Consultant,
Anagran, Inc.,
24, Keswick Close
Felixstowe,
Suffolk
IP11 9NZ
Phone: +44 1394 272713
email: j.l.adams1@btinternet.com
Professor Jinoo Joung
ETRI(Electronics and Telecommunications Research Institute)
Dept. of Computer Science
Sangmyung University
7 Hongji-dong, Jongro-gu,
Seoul, Korea
Phone: +82-2-2287-5452
email: jjoung@smu.ac.kr
Dr. Jongtae Song
Convergence Network Architecture Research Team
ETRI(Electronics and Telecommunications Research Institute)
161Gajeong-Dong,
Yuseong-Gu,
DAEJEON
305-350, Repulic of KOREA
Phone: +82-42-860-5789
Fax: +82-42-860-6342
email: jsong@etri.re.kr
Phone: +82-2-2287-5452
email: jjoung@smu.ac.kr