Network Working Group H. Okita Internet-Draft T. Iijima Intended status: Informational Hitachi, Ltd. Expires: January 10, 2008 Y. Atarashi Alaxala Corp. July 9, 2007 A NETCONF Datamodel for Diff-Serv QoS Control Configuration draft-okita-ngo-diffservdatamodel-01 Status of this Memo 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 January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Okita, et al. Expires January 10, 2008 [Page 1] Internet-Draft Diff-Serv NETCONF datamodel July 2007 Abstract This memo proposes a NETCONF datamodel for Differentiated Service (Diff-Serv) QoS control and an XML Schema to define the model. This model contains functional elements on a Diff-Serv router and Traffic Data Path. In this model, each Traffic Data Path is represented as the combination of the functional elements. Network operators can configure Diff-Serv routers distributed in their provider network by this datamodel and NETCONF protocol. Okita, et al. Expires January 10, 2008 [Page 2] Internet-Draft Diff-Serv NETCONF datamodel July 2007 1. Introduction Integration of various network services is active in enterprise networks for operational cost reduction. Variety of the network services increases complexity of the network device configuration in the enterprise networks. IETF netconf WG made up NETCONF protocol [1] , standard configuration protocol between a network management system and network devices. By using this unified management/configuration protocol, operators can reduce management/configuration cost. This memo proposes a configuration datamodel for the NETCONF protocol to manage or configure the provider's network to which Diff-Serv QoS control is applied. Section 2 describes the NETCONF protocol and Diff-Serv management model as the background of the proposed datamodel. Section 3 describes the proposed Diff-Serv NETCONF configuration datamodel. Okita, et al. Expires January 10, 2008 [Page 3] Internet-Draft Diff-Serv NETCONF datamodel July 2007 2. Background 2.1. NETCONF Protocol Characteristics of the NETCONF protocol are (1) XML-format, (2) RPC- style, and (3) separation of operation and datamodel. The NETCONF protocol has protocol messages described in XML [13] format. XML-format makes it easy for operators to read configuration data. It also improves machine readability of the configuration data since XML documents are well-formed. From a different viewpoint, various XML related tools eases development of devices compliant to the NETCONF protocol. The NETCONF protocol is a Remote Procedure Call (RPC) style protocol. RPC-style protocols have sets of a request message and a corresponding reply message. It is easy to implement on a management software, since each RPC of the protocol corresponds to a function call of the programs. Layer Example +-------------+ +-----------------------------+ (4) | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (3) | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (2) | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (1) | Transport | | SSH, SSL, console, | | Protocol | | SOAP/HTTP, BEEP | +-------------+ +-----------------------------+ Figure 1 The NETCONF protocol defines protocol operations and datamodels separately. The NETCONF protocol has four layers. Figure 1 shows the NETCONF protocol structure. It contains Transport Protocol Layer, RPC Layer, Operations Layer and Content Layer. In the RPC Layer and Operations Layer, the netconf WG defined RPC Okita, et al. Expires January 10, 2008 [Page 4] Internet-Draft Diff-Serv NETCONF datamodel July 2007 message and basic protocol operations [1] . These NETCONF operations carry configuration data inside element. The WG also defined the transport mapping of the NETCONF protocol for SSH [2] , SOAP/HTTP [3] and BEEP [4] . The Content Layer defines model of the NETCONF content carried by NETCONF operations such as and . The structure of the configuration data is defined by schema language such as DTD [13] , XML Schema [14] or RelaxNG for the each model. 2.2. Diff-Serv QoS Control Differentiated Service (Diff-Serv) is a QoS control model for service provider's large scale network. In the Diff-Serv network, traffic flows with different quality defined for each service class. In the Diff-Serv Architecture [5] network, the edge router of Diff- Serv Domain receives packets from the outside, modulates the Diff- Serv field in the packets, and forwards the packets into the Diff- Serv domain. The Core Router in the Diff-Serv Domain forwards packets with the Per-Hop Behavior (PHB) corresponding to the designated DSCP in the DS field of these packets. In the Diff-Serv framework, RFC2474 [9] defines format and usage of the Diff-Serv field. It also defines a default PHB. In addition to the default PHB, two standard PHBs, Assured Forwarding (AF) PHB Group [10] and An Expedited Forwarding PHB [11] are defined with their codepoint. 2.3. Management Model of Diff-Serv Informal management model for Diff-Serv routers [7] are proposed for the management and configuration of Diff-Serv routers. In this model, Diff-Serv routers contain a routing core and Diff-Serv functions at ingress/egress network interfaces. The Diff-Serv functions include classifiers, meters, action elements and queues. The action elements are DSCP markers, absolute droppers, multiplexers, counters and null action element. In this model, operators describe the Diff-Serv router's function as combination of these functional elements. According to the management model, MIB for the Diff-Serv architecture [6] is proposed. It defines diffServDataPath, diffServClassifier, diffServMeter, diffServTBParam, diffServAction, diffServAlgDrop, diffServQueue and diffServScheduler object groups. Operators can access to the management and configuration information on the Diff- Serv routers with this MIB and SNMP [12] . Okita, et al. Expires January 10, 2008 [Page 5] Internet-Draft Diff-Serv NETCONF datamodel July 2007 3. Diff-Serv NETCONF Configuration Datamodel 3.1. Configuration Model Architecture NETCONF configuration datamodel has multiple configuration models. It involves a network interface configuration, a VLAN configuration, an access control list configuration, a Diff-Serv configuration, and an authentication configuration. Figure 2 shows whole NETCONF configuration datamodel architecture. It can be extended by adding a new configuration model. +---------------+ |Config | +---------------+ |+Interface |<>---+ |+VLAN |<>---|+ |+AccessList |<>---||+ |+DiffServ |<>---|||+ |+Authentication|<>---||||+ +---------------+ ||||| +----------------+|||+-----------------------+ | +-------+|+----------+ | | | | | | | | | | | +---------+ +----+ +----------+ +--------+ +--------------+ |Interface| |VLAN| |AccessList| |DiffServ| |Authentication| +---------+ +----+ +----------+ +--------+ +--------------+ +---------+ +----+ +----------+ +--------+ +--------------+ Figure 2 3.2. Datamodel Structure The structure of the proposed configuration datamodel follows structure of the informal Diff-Serv management model [6] . Each element in this NETCONF datamodel is equivalent to a functional element in the informal Diff-Serv management model. Figure 3 shows the architecture of the proposed Diff-Serv Configuration datamodel. This proposed configuration datamodel defines element. This element is the top element of the Diff-Serv configuration data. In addition to this element, this datamodel defines following elements: , , , , , , and . To configure Diff-Serv function on a Diff-Serv router, operators Okita, et al. Expires January 10, 2008 [Page 6] Internet-Draft Diff-Serv NETCONF datamodel July 2007 should connect above elements to form a Traffic Data Path. This Traffic Data Path represents which element packets received by a network interface would pass. +--------------------------------------------------------------+ | diffServType | +--------------------------------------------------------------+ | dataPath | | classifier | | meter | | marker | | scheduler | | dropper | +--------------------------------------------------------------+ <> <> <> <> <> <> | | | | | | | | | | | | +------------+ | +-----------------------+ | +----------------+ | |dataPathType| | |meterType | | |schedulerType | | +------------+ | +-----------------------+ | +----------------+ | |interface | | |threshold | | |schedulingMethod| | |ifDirection | | |nonConformOutputElement| | |queueDropMethod | | |startElement| | | | | |queue | | +------------+ | +-----------------------+ | |endElement | | | | +----------------+ | | | | +--------------+ +-----------+ +-----------+ |classifierType| |markerType | |dropperType| +--------------+ +-----------+ +-----------+ |classifierUnit| |dscp | +-----------+ +--------------+ |nextElement| +-----------+ Figure 3 3.3. Datamodel Elements This section describes the XML elements defined in the Diff-Serv configuration datamodel. 3.3.1. DataPath element The element represents the object which becomes the entrance of each network interface of a router and which receives traffic flow from outside the router (Ingress side) and from inside switch fabric (Egress side). Okita, et al. Expires January 10, 2008 [Page 7] Internet-Draft Diff-Serv NETCONF datamodel July 2007 The element SHOULD take an interface name and a name of the output object. The interface name is defined outside this datamodel. The output object is one of the functional element objects defined in this configuration datamodel. It MAY have direction of received traffic if a target router has a capability to configure egress and ingress side respectively. 3.3.2. Classifier element The element represents the object which classifies the input traffic flow. The object extracts the flow that fulfils the given condition. The element SHOULD take at least one element to know the flow selection condition. The element is a container of the elements. The element SHOULD take src/dst IP address, protocol number, src/dst TCP/UDP port number, or Diff-Serv Code Point (DSCP) to indicate the condition. The element SHOULD take next element name defined in this configuration datamodel. 3.3.3. Marker element The element represents the object which rewrites a DSCP field of received packets. This element SHOULD take element to indicate what code point is set. 3.3.4. Meter element The element represents the object which measures the bandwidth of input flow and which separates it into multiple flows with respective rate values. The element SHOULD take an output element name. The output element receives non-conform flow from the element which exceeds the max rate. It SHOULD also take at least one element to know the threshold rate and its output element. Each of the element SHOULD take element and element. 3.3.5. Dropper element The element represents the object which silently discards received packets. Okita, et al. Expires January 10, 2008 [Page 8] Internet-Draft Diff-Serv NETCONF datamodel July 2007 3.3.6. Scheduler element The element represents the object which controls the output order from multiple queues and the discard order in the queues. This object prioritizes the multiple flows separated in the classifier functional element. The element SHOULD take at least one element. The element represents the queues on each network interface on the router. Each element SHOULD take priority number which decides output order between the multiple queues. The element SHOULD take a element to indicate its scheduling method between its multiple queues. The element takes one of the following option: priority, Weighted Round Robin (WRR), or Weighted Fair Queueing (WFQ). The element SHOULD take a element to indicate the packet discard method for its queues. The takes either tailDrop or Random Early Detection (RED). 3.4. XML Schema of Diff-Serv NETCONF Datamodel XML Schema of the Diff-Serv NETCONF configuration datamodel. Okita, et al. Expires January 10, 2008 [Page 10] Internet-Draft Diff-Serv NETCONF datamodel July 2007 A Differentiated Services Code-Point that may be used for marking a traffic stream. Okita, et al. Expires January 10, 2008 [Page 11] Internet-Draft Diff-Serv NETCONF datamodel July 2007 3.5. Configuration Example This section describes an example configuration of a Diff-Serv router in a service provider's network. The target network has a Diff-Serv domain composed of multiple Diff- Serv routers. Figure 5 shows the model of the target network. An edge router of the Diff-Serv routers is connected to a external router taking a subnet whose network address and mask length are 128.0.1.10/16. Okita, et al. Expires January 10, 2008 [Page 13] Internet-Draft Diff-Serv NETCONF datamodel July 2007 +-------------+ | | | +------+ +------------------+ +------+ | |router|--+ | | +--|router| | +------+ | | | | +------+ |128.0.1.10/16| | +------+ +------+ +------+ | +-------------+ +--|Edge |--|Core |--|Edge |--+ +--|Router| |Router| |Router|--+ | +------+ +------+ +------+ | +------+ | | | | +------+ |router|--+ | Diff-Serv Domain | +--|router| +------+ +------------------+ +------+ Figure 5 Figure 6 shows the configuration model of the data path on the edge router, which treats the packets from 128.0.1.10/16 subnet. As the start point, data-path functional element appears and is assigned to the network interface connected to the external router. A classifier element follows the data-path element and separates received packets into a group whose packets' source address is in subnet 128.0.1.10/16 and a group of other packets. +-----------+ +----+ +----+ |+-----+ | +->|Mar-|-->|Me- |------------>||Queue| | +-----+ +-------+ | | ker| | ter|-+ +----+ |+-----+ | |Data |-->|Classi-|-+ +----+ +----+ +->|Dro-| | | | Path| | fier|-+ |pper| | | +-----+ +-------+ | +----+ |+-----+ | +----------------------------->||Queue| | |+-----+ | |Traffic | |Conditioner| +-----------+ Figure 6 Below is a NETCONF-style configuration example for the edge router of the Diff-Serv domain in the service provider's network. Okita, et al. Expires January 10, 2008 [Page 14] Internet-Draft Diff-Serv NETCONF datamodel July 2007 gigabitEthernet0/7 in clfr1 128.0.1.10 16 mkr1 any que1 46 mtr1 30Mbps que8 drp1 8 1 Okita, et al. Expires January 10, 2008 [Page 15] Internet-Draft Diff-Serv NETCONF datamodel July 2007 3.6. Other Referred NETCONF Datamodel The proposed Diff-Serv NETCONF datamodel refers InetAddress datatypes to describe IP addresses object in its configuration. For example, a classifier element contains IP address type elements to indicate a set of packets to be selected for each output of the classifier element. 3.7. Cross Reference between Functional Elements 3.7.1. RowPointer Problem in MIB As said above, Diff-Serv MIB describes Traffic Data Path as linked list of functional elements. Diff-Serv MIB use a RowPointer type object to refer the functional element(s) following an element on a Traffic Data Path. The RowPointer type object can be an Object Identifier (OID). The OID indicates an entry on a MIB table, for example, diffServClassifierElementTable. The problem is ambiguity of RowPointer semantics. The OID can indicate every object on the whole MIB tree. When operators configure routers using Diff-Serv MIB, they should search the OID corresponding with the proper entry on the MIB table from whole MIB tree. This makes it complicated the router configurations. 3.7.2. Hierarchical Expression in XML document Generally in a XML document, hierarchical relationship between multiple objects in a data structure can be described by the set of a parent element and a child element. For example, in a NETCONF configuration, network interface and assigned IP address can be described like that. Below is an example of the NETCONF configuration for two network interfaces that address 192.168.1.1/24 and 192.168.2.1/24 are assigned respectively. gigabitEthernet0/7 192.168.1.1/24 gigabitEthernet0/8 192.168.2.1/24 Okita, et al. Expires January 10, 2008 [Page 16] Internet-Draft Diff-Serv NETCONF datamodel July 2007 As explained in Section 2.3 , in the Diff-Serv configuration model, a functional element could be linked from multiple functional elements. For example, both two classifier elements indicate a same meter element as their next destination of treated packets. The Diff-Serv NETCONF datamodel should not adopt the hierarchical expression above. The Diff-Serv NETCONF datamodel which adopts this hierarchical expression would make it complicated for operators to manage configurations. When parameters of a functional element linked by multiple elements are changed, operators would meet trouble to change all elements in the configuration corresponding to the parameter-changed element respectively. 3.7.3. ID Reference Type Usage in NETCONF datamodel To avoid the problem, The Diff-Serv NETCONF datamodel uses an ID type attribute and an IDREF type attribute to form a reference between two functional elements on a Traffic Data Path. Semantically, candidates of an IDREF type attribute in a Diff-Serv NETCONF configuration document are limited to the set of ID type attribute defined in the configuration document. Operators can easily select proper IDREF type value indicating a target functional element. Below is an example configuration of a Traffic Data path object on a router. The Traffic Data Path object indicates a corresponding network interface on the router. The object refers a classifier object in a startElement tag as an element which receives traffic from the interface at first. gigabitEthernet0/7 in clfr1 gigabitEthernet0/8 in clfr1 Okita, et al. Expires January 10, 2008 [Page 17] Internet-Draft Diff-Serv NETCONF datamodel July 2007 Also, the XML standard allows us to use KEY/KEYREF elements to represent the relationship between cross-referred objects. The KEY/ KEYREF elements can define multiple ID space for the keys represented by KEY elements, and solve the problem that ID/IDREF elements have only a single ID space. By using KEY/KEYREF element, operators can assign simple ID for each object. (TBD) Okita, et al. Expires January 10, 2008 [Page 18] Internet-Draft Diff-Serv NETCONF datamodel July 2007 4. Security Consideration In the NETCONF architecture, the transport protocol layer is responsible for the security between a network manager and network devices. Okita, et al. Expires January 10, 2008 [Page 19] Internet-Draft Diff-Serv NETCONF datamodel July 2007 5. IANA Consideration This document has no actions for IANA. Okita, et al. Expires January 10, 2008 [Page 20] Internet-Draft Diff-Serv NETCONF datamodel July 2007 6. References 6.1. Normative References [1] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [2] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006. [3] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006. [4] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006. [5] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [6] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002. [7] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. 6.2. Informative References [8] Admankar, S. and S. Chisholm, "Using XML Schema to define Netconf Content", draft-chisholm-netconf-model-06 (work in progress), February 2007. [9] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [10] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [11] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [12] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Okita, et al. Expires January 10, 2008 [Page 21] Internet-Draft Diff-Serv NETCONF datamodel July 2007 Framework", RFC 3410, December 2002. [13] Bray, T., Paoli, J., Sperberg-McQueen, C., Yergeau, F., and E. Maler, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, . [14] Fallside, D., "XML Schema Part 0: Primer", World Wide Web Consortium FirstEdition REC-xmlschema-0-20010502, May 2001, . [15] Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", World Wide Web Consortium FirstEdition REC-soap12-part1-20030624, June 2003, . Okita, et al. Expires January 10, 2008 [Page 22] Internet-Draft Diff-Serv NETCONF datamodel July 2007 Authors' Addresses Hideki Okita Central Research Laboratory, Hitachi. Ltd. 1-280 Higashi-Koigakubo Kokubunji, Tokyo 185-8601 Japan Phone: +81-42-323-1111 Fax: +81-42-323-7868 Email: hideki.okita.pf@hitachi.com Tomoyuki Iijima Central Research Laboratory, Hitachi. Ltd. 1-280 Higashi-Koigakubo Kokubunji, Tokyo 185-8601 Japan Phone: +81-42-323-1111 Fax: +81-42-323-7868 Email: tomoyuki.iijima.fg@hitachi.com Yoshifumi Atarashi Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1200 Fax: +81-44-549-1272 Email: atarashi@alaxala.net Okita, et al. Expires January 10, 2008 [Page 23] Internet-Draft Diff-Serv NETCONF datamodel July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Intellectual Property 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Okita, et al. Expires January 10, 2008 [Page 24]