Network Working Group Shunyi Zhang Internet Draft NJUPT Intended status: Experiment Ling Tan Expires: November 27, 2010 NJUPT Xiangyan Ning NJUPT Shoumei Xu NJUPT Yong Li NJUPT May 30, 2010 The Definition of Unified Traffic draft-shunyi-unified-traffic-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 Shunyi Zhang Expires November 27, 2010 [Page 1] Internet-Draft The Definition of Unified Traffic May 2010 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 27, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes a list of DSCP value of hundreds service type in order to make a precise priority, which can be applied by differentiated traffic conditioning policies. A Routing optimization based on traffic identification is then proposed, which is to execute route selection with the information of both destination address and traffic value. This method can promote the network quality of transmission and finally achieve differentiated services. Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. DSCP Values of Differentiated Application...................3 4. Routing Based on Traffic Identification.....................8 5. Security Considerations.....................................9 6. IANA Considerations.........................................9 7. Normative Reference.........................................9 8. Acknowledgments.............................................9 1. Introduction o This Request for comments (RFC) responses to note differentiated service packets with unique DS code in IP header. Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing of Internet service. Shunyi Zhang Expires November 27, 2010 [Page 2] Internet-Draft The Definition of Unified Traffic May 2010 o The service differentiation architecture permits intermediate nodes to examine and change the value of the DSCP. This document presents a list of DSCP value of hundreds of service types, in order to make a precise priority, which can be applied by differentiated traffic conditioning policies. This document is intended to be read along with the differentiated service architecture [FRC2475]. 2. Terminology This section gives a general conceptual overview of the terms used in this document. Some of these terms are more precisely defined in later sections of this document. Traffic Identification is a method which selects packets based on the content of transport layer or application layer of packet according to defined rules. Service the overall treatment of a defined subset of a customer's traffic within a DS domain or end-to-end. 3. DSCP Values of Differentiated Application When packet arrives at a router, it firstly be processed by the Traffic Identification module, and be noted a specific DSCP value as its application type. Then the router finds the next hop from the proper routing table which is used by packets with this DSCP value. A replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6]. Six bits of the DS field are used as a codepoint (DSCP) to select the PHB (Per Hop Behavior) a packet experiences at each node. A Two-bit currently unused (CU) field is reserved and is defined as ECN Explicit Congestion Notification by IETF. In this document, the CU field is used as an extension of DS field. The DS field structure is presented below: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | DSCP | CU | +---+---+---+---+---+---+---+---+ DSCP: differentiated services codepoint CU: currently unused Shunyi Zhang Expires November 27, 2010 [Page 3] Internet-Draft The Definition of Unified Traffic May 2010 If the DSCP value is higher, the traffic condition may be more efficient. Traffic Identification techniques, including port based on traffic connection behavior and network packet identification method based on machine learning, is an important foundation of many network monitoring management and control methods today. Differentiated Services have different priority requests in the network. For example, the security type applications need rapid and safe network environment, so these application services should be transferred in the first priority. As a result, they should be distributed a high DSCP value. Based on the different priority requests of the current applications, the DSCP value can be distributed as fellows: DSCP value application type 0x00 GRE 0x01 IPSEC 0x02 PPTP 0x03 SWIPE 0x04 SKYPE 0x05 T.120 0x06 VOCALTEC-IPHONE 0x07 PHILIPS-VC-TCP 0x08 POP 0x09 SMTP 0x0a MS Exchange 0x0b IMAP 0x0c IMAPS (Secure IMAP) 0x0d CC-MAIL 0x0e LOTUS-NOTES 0x0f BIFF 0x10 RTSP 0x11 Winamp 0x12 MSplayer 0x13 Realone 0x14 Quicktime 0x15 iTunes Shunyi Zhang Expires November 27, 2010 [Page 4] Internet-Draft The Definition of Unified Traffic May 2010 0x16 NETSHOW 0x17 REALAUDIO 0x18 ARP 0x19 AUTH 0x1a BGP 0x1b BOOTP (DHCP) 0x1c CHARGEN 0x1d CMIP 0x1e DNS 0x1f ECHO 0x20 EGP 0x21 FINGER 0x22 ICMP 0x23 IGMP 0x24 Local MGMT 0x25 NPP 0x26 NTP 0x27 OSPF 0x28 PPPoE 0x29 RIP 0x2a RMON 0x2b SNMP 0x2c TIMESERVER 0x2d TIME 0x2e WHO 0x2f WHOIS 0x30 TACACS 0x31 RADIUS 0x32 NETWARE-IP 0x33 APPLETALK 0x34 APPLETALK Over IP 0x35 GGP 0x36 GOPHER Shunyi Zhang Expires November 27, 2010 [Page 5] Internet-Draft The Definition of Unified Traffic May 2010 0x37 I-NLSP 0x38 IPX 0x39 IPX over IP 0x3a MS-IPX 0x3b NETBEUI 0x3c NETWARE 0x3d Oracle 0x3e SAP 0x3f SQL 0x40 LDAP 0x41 LDAPS 0x42 CORBA 0x43 CYBERCASH 0x44 EXEC 0x45 ALIENS 0x46 ANARCHY 0x47 ASHERONS CALL 0x48 BLACK AND WHITE 0x49 COUNTERSTRIKE 0x4a DARK REIGN 0x4b DIABLO 0x4c DOOM 0x4d ELITE FORCE 0x4e F16 0x4f F22 SIMULATOR 0x50 FIGHTERACE 0x51 HEXEN 0x52 KALI 0x53 KOHAN IMMORTAL 0x54 SOVEREIGNS 0x55 MOTORHEAD 0x56 MSN GAME 0x57 MYTH Shunyi Zhang Expires November 27, 2010 [Page 6] Internet-Draft The Definition of Unified Traffic May 2010 0x58 NEED FOR SPEED 0x59 OPERATION FLASH 0x5a POINT 0x5b OUTLAWS 0x5c QUAKE-TCP 0x5d SWAT3-TCP 0x5e ULTIMA 0x5f UNREAL TOURNAMENT 0x60 ZNES 0x61 FTP 0x62 NETBIOS-IP 0x63 NFS 0x64 SYSLOG 0x65 PRINTER 0x66 PRINT-SRV 0x67 RCP 0x68 SUNRPC 0x69 CMD 0x6a HTTP 0x6b NNTP-TCP 0x6c KAZAA 0x6d EDONKEY 0x6e GNUTELLA 0x6f BitTorrent 0x70 WINMX 0x71 DIRECT CONNECT 0x72 Direct connect 0x73 Blubster 0x74 Piolet 0x75 RockitNet 0x76 Winny 0x77 JABBER 0x78 MADSTER-AIMSTER Shunyi Zhang Expires November 27, 2010 [Page 7] Internet-Draft The Definition of Unified Traffic May 2010 0x79 SoulSeek 0x7a MSN-MESSENGER 0x7b AOL/ICQ 0x7c Yahoo 0x7d IRC 0x7e CITRIX 0x7f MS-RDP-CLIENT 0x80 PCANYWHERE 0x81 TELNET 0x82 TELNETS 0x83 SSH 0x84 RLOGIN 0x85 RTELNET 0x86 X11-TCP 4. Routing Based on Traffic Identification After the identification in the Traffic Identification module, each type of traffic is endowed with a certain DSCP value. In general, traffic with high priority has higher requirements for path parameters, and is consequently provided with a prior service. Furthermore, this module can be used as the basis of routing optimization, which in detail is to execute route selection with the information of both destination address and traffic value (embody the requirements of different application services) rather than with destination address only during the routing phase. In doing so, a user oriented characteristic is also reflected. For example, for traffic to the same destination, if the DSCP value of a certain kind of traffic is 0X10, which means this traffic is real-time stream and has very high demands on delay and bandwidths, then we can choose path with relative low latency; Whereas for those traffic to the same destination that consume considerable bandwidth, e.g. P2P traffic, we should select the best effort path. The performance of paths with low latency or best effort can be configured statically in advance. To provide different routes for different service, we need to sustain multi optional paths that reach the same destination in routing tables, which can be achieved by setting path parameters for each path. During the process searching routing table, the destination address is treated as the first index and the DSCP value of traffic is secondary, then we can find the forwarding hop one by one. Shunyi Zhang Expires November 27, 2010 [Page 8] Internet-Draft The Definition of Unified Traffic May 2010 Thus we can arrange routing according to different traffic requirements based on the route selection with destination, which can promote the network quality of transmission and finally achieve differentiated services. 5. Security Considerations Noting the packets with different DSCP value does not have any direct impact on security. 6. IANA Considerations This document has no IANA considerations. 7. Normative Reference [RFC791] Postel, J., Editor, "Internet Protocol", RFC791, September 1981. [RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC1349, July 1992. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. 8. Acknowledgments The author would like to acknowledge the Differentiated Service Working Group for the Differentiated Services architecture which [RFC2475] helped shape this document. Authors' Addresses Shunyi Zhang Nanjing University of Posts and Telecommunications NO.66 XinMofan Road Nanjing China Phone: 86-025-85882205 Email: dirzsy@njupt.edu.cn Shunyi Zhang Expires November 27, 2010 [Page 9] Internet-Draft The Definition of Unified Traffic May 2010 Ling Tan Nanjing University of Posts and Telecommunications NO.66 XinMofan Road Nanjing China Email: cillatan0@21cn.com Xiangyan Ning Nanjing University of Posts and Telecommunications NO.66 XinMofan Road Nanjing China Email: xyning@126.com Shoumei Xu Nanjing University of Posts and Telecommunications NO.66 XinMofan Road Nanjing China Email: shenlan-tiankong@163.com Yong Li Nanjing University of Posts and Telecommunications NO.66 XinMofan Road Nanjing China Email: liyong_1222@126.com Shunyi Zhang Expires November 27, 2010 [Page 10]