[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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

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

   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

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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


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

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
   Anagran, Inc.,
   24, Keswick Close
   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)
   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

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/