Internet DRAFT - draft-adams-tsvwg-flow-signalling-codepoint

draft-adams-tsvwg-flow-signalling-codepoint





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