From majordomo@raleigh.ibm.com Fri Jul 7 14:39:50 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09371 for ; Fri, 7 Jul 2000 14:39:47 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA28910; Fri, 7 Jul 2000 14:38:06 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA29542; Fri, 7 Jul 2000 14:38:07 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44504; Fri, 7 Jul 2000 14:00:36 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24784; Fri, 7 Jul 2000 14:00:32 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA20414 for ; Fri, 7 Jul 2000 14:00:34 -0400 Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA21584 for ; Fri, 7 Jul 2000 14:00:31 -0400 Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Fri, 7 Jul 2000 13:57:17 -0400 Received: from zcard00b.ca.nortel.com ([47.128.208.105]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3NYT9SXL; Fri, 7 Jul 2000 13:57:07 -0400 Received: from nettonyv (NET-TONYV [141.251.80.42]) by zcard00b.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NK23DC6B; Fri, 7 Jul 2000 13:57:07 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Tony Vasile" To: Policy Mailing List Subject: Auxiliary classes attached to PolicyConditionInstance Date: Fri, 7 Jul 2000 14:02:06 -0400 Message-Id: <002b01bfe83d$7616d480$2a50fb8d@corpnorth.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Tony Vasile" Content-Transfer-Encoding: 7bit Hi, I have a question concerning auxiliary classes and the QoS Schema definition. Certain directory implementations require auxiliary classes to be attached to structural classes as part of the schema definition, and do not return the auxiliary classes attached as part of the objectclass attribute. When reading policyConditionInstance objects from the directory, what is a suggested method of determining which auxiliary classes have been attached to the policyConditionInstance object without having to interrogate the object for instances of attributes that belong to an attached auxiliary class. Thanks, Tony V. Nortel Networks From majordomo@raleigh.ibm.com Fri Jul 7 16:03:39 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11925 for ; Fri, 7 Jul 2000 16:03:38 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA34224; Fri, 7 Jul 2000 16:02:20 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA26462; Fri, 7 Jul 2000 16:02:21 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42994; Fri, 7 Jul 2000 15:30:15 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51690; Fri, 7 Jul 2000 15:30:12 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA35496 for ; Fri, 7 Jul 2000 15:30:14 -0400 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA33694 for ; Fri, 7 Jul 2000 15:30:08 -0400 Received: from ysnirnt70 ([144.254.95.24]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id WAA22606; Fri, 7 Jul 2000 22:31:40 +0300 (IDT) From: "Yoram Snir" To: "'Tony Vasile'" , "'Policy Mailing List'" Subject: RE: Auxiliary classes attached to PolicyConditionInstance Date: Fri, 7 Jul 2000 22:26:44 +0200 Message-Id: <002501bfe851$ab6d1130$0200000a@ysnirnt70> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <002b01bfe83d$7616d480$2a50fb8d@corpnorth.baynetworks.com> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit Tony, In order to overcome implementation problem of some directory servers you might need to check whether certain attributes, belonging to specific aux classes you are looking for are available in a certain object. Regards, ------------------------------------------------------------- Yoram Snir Cisco Systems Tel. +972-9-9700085 Mobile +972-54-970085 ------------------------------------------------------------- -----Original Message----- From: policy-owner@raleigh.ibm.com [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Tony Vasile Sent: Friday, July 07, 2000 8:02 PM To: Policy Mailing List Subject: Auxiliary classes attached to PolicyConditionInstance Hi, I have a question concerning auxiliary classes and the QoS Schema definition. Certain directory implementations require auxiliary classes to be attached to structural classes as part of the schema definition, and do not return the auxiliary classes attached as part of the objectclass attribute. When reading policyConditionInstance objects from the directory, what is a suggested method of determining which auxiliary classes have been attached to the policyConditionInstance object without having to interrogate the object for instances of attributes that belong to an attached auxiliary class. Thanks, Tony V. Nortel Networks From majordomo@raleigh.ibm.com Sun Jul 9 06:59:44 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07426 for ; Sun, 9 Jul 2000 06:59:43 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA35922; Sun, 9 Jul 2000 06:57:56 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA06326; Sun, 9 Jul 2000 06:57:58 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23298; Sun, 9 Jul 2000 06:28:34 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48874; Sun, 9 Jul 2000 06:28:30 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA26822 for ; Sun, 9 Jul 2000 06:28:33 -0400 Received: from tantalum (tantalum.btinternet.com [194.73.73.80]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA35886 for ; Sun, 9 Jul 2000 06:28:28 -0400 Received: from [212.140.202.98] (helo=HomePC.doc.ic.ac.uk) by tantalum with esmtp (Exim 3.03 #83) id 13BEK4-00051e-00 for policy@raleigh.ibm.com; Sun, 09 Jul 2000 11:28:28 +0100 Message-Id: <4.3.1.2.20000709112717.00b54100@dse-mail.doc.ic.ac.uk> X-Sender: mss@dse-mail.doc.ic.ac.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 09 Jul 2000 11:28:00 +0100 To: policy@raleigh.ibm.com From: Morris Sloman Subject: Policy 2001 Deadline 31 July Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Morris Sloman Policy 2001: Workshop on Policies for Distributed Systems and Networks 29-31 January 2001 Hosted by: HP Laboratories, Bristol, UK Technical Co-sponsored by IEEE ComSoc (not yet approved) See: http://www-dse.doc.ic.ac.uk/events/policy-2001/ for the latest information Policy based systems are the subject of a wide range of activities in universities, standardisation bodies and within industry. They have a wide spectrum of applications ranging from quality of service management within networks to security and enterprise modelling. This workshop will provide a forum for discussion and collaboration between researchers, developers and users of policy based systems. It will bring together the various communities working on policy and follows on from the successful informal Policy Workshop held in November 1999 (see http://www-dse.doc.ic.ac.uk/events/policy-99/). Within the Internet community there is considerable interest in Policy Based Networking. A number of companies have announced tools to support the specification and deployment of policies. Much of this work is focused on policies for quality of service management within networks and the Internet Engineering and Distributed Management Task Forces (IETF/DMTF) is actively working on standards related to this area (see http://www-dse.doc.ic.ac.uk/research/policies for links). The Security community has focused on the specification and analysis of access control policy which has evolved into the work on Role-Based Access Control (RBAC). There has been work over a number of years in the academic community on specification and analysis of policies for Distributed Systems mostly concentrating on authorisation policies. Although there are strong similarities in the concepts and techniques used by the different communities there is no commonly accepted terminology or notation for specifying policy. Several research groups are looking at high-level aspects of policy related to Enterprise Modelling. An ISO Open Distributed Processing working group is defining Policy and Role concepts within the Enterprise Viewpoint. Enterprise goals or Service Level Agreements can be considered as high-level abstract policies which must be progressively refined into implementable policies. The work on the specification and analysis of Business Rules is also relevant. The common concept of policy, within all of the above communities, is that polices define a set of rules governing choices in the behaviour of the system. The motivation is to be able to modify policy in order to change system behaviour without having to re-implement the system, or restructure the requirements specification. -------------------------------------------------------------------------- Authors are invited to submit papers addressing but not limited to the following topics: Abstractions and Notations for Policy Specification Security Policies and Role Based Access Control Management Policies Policy Based Networking Implementation Models and Techniques Services for Storing and Manipulating Policies Policy Support for Active Networks and Mobile Environments Application-Specific Policy Frameworks Policy Refinement Policy Analysis Business Rules Standardisation Activities Case Studies The emphasis of the workshop will be on practical approaches to policy, however, novel contributions are encouraged. Workshop format --------------- The workshop will include both invited papers and presentations on accepted refereed papers which will be published (probably by IEEE Press) in a proceedings. There will be substantial time allocated for discussions as well as panel sessions. PAPER SUBMISSIONS ----------------- Paper submissions must present original, unpublished research or experiences. They should be full papers and be no longer than 10 pages IEEE double column format. Submissions must include a cover page in ASCII format, containing the title, author name(s) and affiliation(s), the complete address (telephone, fax, email) of the corresponding author, and an abstract (max 150 words) followed by up to 5 keywords. Papers under review elsewhere must not be submitted to Policy 2000. Authors are requested to submit papers in electronic PDF or Postscript format. Instructions for electronic submissions will be available at the following URL: http://www-dse.doc.ic.ac.uk/events/policy-2001/ IMPORTANT DATES July 31, 2000: Submission of Full Papers September 26, 2000: Notifications of Acceptance October 26, 2000: Camera-ready Papers Due Date January 29-31, 2001 Workshop Local Arrangements ------------------ The workshop will be held at Hewlett-Packard's European research centre in Bristol. It is conveniently reached by road and rail (to Bristol Parkway Station) from London and Heathrow Airport. It takes approximately 80 minutes by train from London, Paddington. Directions and local information can be found at the HP's web site: http://www-uk.hpl.hp.com Hotel rooms will reserved at a local hotel. Details and costs to be provided. Organising Committee --------------------- Conference Chair Morris Sloman Department of Computing, Imperial College London SW7 2BZ, UK Phone: +44 20 7594 8279 Fax: +44 20 7581 8024 email: m.sloman@doc.ic.ac.uk Program Co-Chairs Emil Lupu Department of Computing, Imperial College Phone: +44 20 7594 8249 Fax: +44 20 7581 8024 London SW7 2BZ, UK email: e.c.lupu@doc.ic.ac.uk Jorge Lobo Bell Labs 600 Mountain Ave., 2c-219 Murray Hill, NJ 07974, USA Voice: +1-908-582-1731 Fax: +1-908-582-4092 Mail: jlobo@research.bell-labs.com Program Committee ------------------ David Black, EMC, USA Matt Blaze, AT&T, USA Jan Chomicki, Monmouth University, USA Naranker Dulay, Imperial College, UK Ed Ellesson, Tivoli Systems, USA Francisco Garcia, Agilent Laboratories, Scotland Cheh Goh, HP Labs, Bristol, UK Kohei Iseda, Fujitsu Laboratories, Japan Peter Linington, University of Kent, UK Hugh Mahon, HP, USA Ian Marshall, BT Labs., UK Zoran Milosevic, DSTC, Brisbane, Australia Naftaly Minksy, Rutgers University, USA Jonathan Moffett, University of York, UK Ken Moody, Cambridge University, UK Ravi Sandhu, George Mason University, USA Edgar Sibley, George Mason University, USA John Strassner, Cisco, USA Vijay Varadharajan, University of Western Sydney, Australia Dinesh Verma, IBM, USA Andrea Westerinen, SNIA, USA Local Organisation: ------------------- Jan Ward Events Co-ordinator HP Labs, Bristol Phone: +44 117 312 8032 Fax: +44 117 312 9364 email: jan@hplb.hpl.hp.com From majordomo@raleigh.ibm.com Sun Jul 9 16:31:33 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10505 for ; Sun, 9 Jul 2000 16:31:32 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA11760; Sun, 9 Jul 2000 16:29:44 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA30024; Sun, 9 Jul 2000 16:29:44 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34994; Sun, 9 Jul 2000 15:55:52 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36770; Sun, 9 Jul 2000 15:55:49 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA19748 for ; Sun, 9 Jul 2000 15:55:52 -0400 Received: from bgslc02.TBG.COM ([63.99.125.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA21696 for ; Sun, 9 Jul 2000 15:55:50 -0400 Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id <3LKVQNT4>; Sun, 9 Jul 2000 13:47:26 -0600 Message-Id: <0C875DC28791D21192CD00104B95BFE7C578E1@BGSLC02> From: Dave Kosiur To: Policy Mailing List Subject: Policy Description Language? Date: Sun, 9 Jul 2000 13:47:16 -0600 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Dave Kosiur What, if any, work has been done on defining a PDL for describing and exchanging policies between policy-based systems? I know Strassner had submitted an internet draft more than a year ago, but I'm not aware of anything since. Is some form of XML going to be the answer? Dave From majordomo@raleigh.ibm.com Sun Jul 9 18:25:56 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11343 for ; Sun, 9 Jul 2000 18:25:56 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA22884; Sun, 9 Jul 2000 18:24:51 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA35866; Sun, 9 Jul 2000 18:24:51 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44064; Sun, 9 Jul 2000 17:57:18 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46360; Sun, 9 Jul 2000 17:57:15 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA37050 for ; Sun, 9 Jul 2000 17:57:19 -0400 Received: from mail2.hispeedhosting.com (mail2.hispeedhosting.com [209.201.116.19]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA31674 for ; Sun, 9 Jul 2000 17:57:15 -0400 Received: from Gast [213.8.203.17] by mail2.hispeedhosting.com (SMTPD32-6.00) id A539E1BA01FE; Sun, 09 Jul 2000 17:57:13 -0400 Message-Id: <001401bfe9f9$1ce28900$11cb08d5@bbdo.de> From: "Noriko Hata" To: "Dave Kosiur" , "Policy Mailing List" References: <0C875DC28791D21192CD00104B95BFE7C578E1@BGSLC02> Subject: Re: Policy Description Language? Date: Mon, 10 Jul 2000 00:56:14 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Noriko Hata" Content-Transfer-Encoding: 7bit Hi, this message is forwarded to the Policy wg for Ofer Avineri; Yes! There have been some discussions in that perspective, It should be probably be aligned with John's descriptive definitions toward a schema DTD, Ofer. Regards, Noriko Hata Digital Intelligence Systems, Inc. ----- Original Message ----- From: Dave Kosiur To: Policy Mailing List Sent: Sunday, July 09, 2000 9:47 PM Subject: Policy Description Language? | What, if any, work has been done on defining a PDL for describing and | exchanging policies between policy-based systems? I know Strassner had | submitted an internet draft more than a year ago, but I'm not aware of | anything since. Is some form of XML going to be the answer? | | Dave | | From majordomo@raleigh.ibm.com Mon Jul 10 08:49:30 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06730 for ; Mon, 10 Jul 2000 08:49:27 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA27538; Mon, 10 Jul 2000 08:48:10 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA07096; Mon, 10 Jul 2000 08:48:10 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30830; Mon, 10 Jul 2000 08:13:00 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26914; Mon, 10 Jul 2000 08:12:54 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA20710 for ; Mon, 10 Jul 2000 08:12:54 -0400 Received: from groucho.doc.ic.ac.uk (IDENT:root@groucho.doc.ic.ac.uk [146.169.14.3]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA22070 for ; Mon, 10 Jul 2000 08:12:52 -0400 Received: from dse-pc-mss.doc.ic.ac.uk (dse-pc-mss.doc.ic.ac.uk [146.169.14.135]) by groucho.doc.ic.ac.uk (8.9.3/8.9.3) with ESMTP id NAA01616 for ; Mon, 10 Jul 2000 13:12:46 +0100 Message-Id: <4.3.1.2.20000710125919.00bfe840@dse-mail.doc.ic.ac.uk> X-Sender: mss@dse-mail.doc.ic.ac.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 10 Jul 2000 13:04:32 +0100 To: Policy Mailing List From: Morris Sloman Subject: Policy Description Language? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Morris Sloman >From: Dave Kosiur >To: Policy Mailing List >Subject: Policy Description Language? >Date: Sun, 9 Jul 2000 13:47:16 -0600 >Mime-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2650.21) >Content-Type: text/plain >Sender: policy-owner@raleigh.ibm.com >Precedence: bulk >Reply-To: Dave Kosiur >Status: > >What, if any, work has been done on defining a PDL for describing and >exchanging policies between policy-based systems? I know Strassner had >submitted an internet draft more than a year ago, but I'm not aware of >anything since. Is some form of XML going to be the answer? > >Dave We have defined Ponder - a declarative, object-oriented language for specifying Management and security policies. see http://www-dse.doc.ic.ac.uk/policies/ponder.html We are working on an XML back-end There has been some discussions, with some members in the group, on using this language. Morris Sloman __________________________________________________ **** Note new phone numbers Professor Morris Sloman Imperial College of Science Technology and Medicine Department of Computing 180 Queen's Gate London SW7 2BZ, U.K. Phone: +44 20 7594 8279 Fax: +44 20 7581 8024 Email: m.sloman@doc.ic.ac.uk WWW: http://www-dse.doc.ic.ac.uk/~mss From majordomo@raleigh.ibm.com Mon Jul 10 18:34:39 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00807 for ; Mon, 10 Jul 2000 18:34:34 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA29460; Mon, 10 Jul 2000 18:32:11 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA24466; Mon, 10 Jul 2000 18:32:13 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42928; Mon, 10 Jul 2000 18:01:06 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42564; Mon, 10 Jul 2000 18:00:55 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA29818 for ; Mon, 10 Jul 2000 18:00:59 -0400 Received: from hotmail.com (law2-f153.hotmail.com [216.32.181.153]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id SAA26374 for ; Mon, 10 Jul 2000 18:00:55 -0400 Received: (qmail 42846 invoked by uid 0); 10 Jul 2000 22:00:18 -0000 Message-Id: <20000710220018.42845.qmail@hotmail.com> Received: from 24.5.72.99 by www.hotmail.com with HTTP; Mon, 10 Jul 2000 15:00:18 PDT X-Originating-Ip: [24.5.72.99] From: "sheri li" To: m.sloman@doc.ic.ac.uk, policy@raleigh.ibm.com Subject: Re: Policy Description Language? Date: Mon, 10 Jul 2000 15:00:18 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "sheri li" Suppose there is a XML DTD defined for Policy Description Language. What would ponder provide more than a XML DTD could to policy definition and validation? Thanks. Sheri Li Aventail Corp. >From: Morris Sloman >Reply-To: Morris Sloman >To: Policy Mailing List >Subject: Policy Description Language? >Date: Mon, 10 Jul 2000 13:04:32 +0100 > > >>From: Dave Kosiur >>To: Policy Mailing List >>Subject: Policy Description Language? >>Date: Sun, 9 Jul 2000 13:47:16 -0600 >>Mime-Version: 1.0 >>X-Mailer: Internet Mail Service (5.5.2650.21) >>Content-Type: text/plain >>Sender: policy-owner@raleigh.ibm.com >>Precedence: bulk >>Reply-To: Dave Kosiur >>Status: >> >>What, if any, work has been done on defining a PDL for describing and >>exchanging policies between policy-based systems? I know Strassner had >>submitted an internet draft more than a year ago, but I'm not aware of >>anything since. Is some form of XML going to be the answer? >> >>Dave > > > >We have defined Ponder - a declarative, object-oriented language for >specifying Management and security policies. > >see http://www-dse.doc.ic.ac.uk/policies/ponder.html > >We are working on an XML back-end > >There has been some discussions, with some members in the group, on using >this language. > >Morris Sloman >__________________________________________________ >**** Note new phone numbers > >Professor Morris Sloman >Imperial College of Science Technology and Medicine >Department of Computing >180 Queen's Gate >London SW7 2BZ, U.K. >Phone: +44 20 7594 8279 Fax: +44 20 7581 8024 >Email: m.sloman@doc.ic.ac.uk >WWW: http://www-dse.doc.ic.ac.uk/~mss > ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From majordomo@raleigh.ibm.com Tue Jul 11 09:22:43 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29565 for ; Tue, 11 Jul 2000 09:22:42 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA30036; Tue, 11 Jul 2000 09:18:39 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA30538; Tue, 11 Jul 2000 09:18:40 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36130; Tue, 11 Jul 2000 08:34:29 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15122; Tue, 11 Jul 2000 08:34:25 -0400 Received: from lmr (dyn9-37-49-166.raleigh.ibm.com [9.37.49.166]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA31566; Tue, 11 Jul 2000 08:34:25 -0400 Message-Id: <000b01bfeb34$aa215080$a6312509@raleigh.ibm.com> From: "Lee Rafalow" To: "Dave Kosiur" Cc: References: <0C875DC28791D21192CD00104B95BFE7C578E1@BGSLC02> Subject: Re: Policy Description Language? Date: Tue, 11 Jul 2000 08:36:40 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Lee Rafalow" Content-Transfer-Encoding: 7bit Dave, The working group made an explicit decision to postpone any consideration of PDLs at least until we have a common model. As previous responses have indicated, there are other efforts and some of them use XML. Since the model derives from CIM, one candidate for IETF standards might be to start by looking at CIM XML. See http://www.dmtf.org/spec/wbem.html for more information. Lee ----- Original Message ----- From: "Dave Kosiur" To: "Policy Mailing List" Sent: Sunday, July 09, 2000 3:47 PM Subject: Policy Description Language? > What, if any, work has been done on defining a PDL for describing and > exchanging policies between policy-based systems? I know Strassner had > submitted an internet draft more than a year ago, but I'm not aware of > anything since. Is some form of XML going to be the answer? > > Dave From majordomo@raleigh.ibm.com Mon Jul 17 12:10:10 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14251 for ; Mon, 17 Jul 2000 12:10:06 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA08072; Mon, 17 Jul 2000 12:06:33 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA31762; Mon, 17 Jul 2000 12:06:34 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37710; Mon, 17 Jul 2000 11:32:41 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38210; Mon, 17 Jul 2000 11:32:36 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA21250 for ; Mon, 17 Jul 2000 11:32:38 -0400 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA07350 for ; Mon, 17 Jul 2000 11:32:33 -0400 Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6HFVnR15329; Mon, 17 Jul 2000 11:31:49 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id LAA00502; Mon, 17 Jul 2000 11:31:49 -0400 (EDT) Message-Id: <200007171531.LAA00502@monday.research.telcordia.com> Date: Mon, 17 Jul 2000 11:31:49 -0400 (EDT) From: Ritu Chadha Subject: Policy Information Model for MPLS Traffic Engineering To: policy@raleigh.ibm.com, mpls@UU.NET Cc: chadha@mailee.research.telcordia.com Mime-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Flink_of_Cows_031_000 X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ritu Chadha --Flink_of_Cows_031_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jtU8Zv8aHhuz564OAhAfRA== FYI: The attached draft was submitted on 7/14/00 and will shortly be available in the IETF Internet Drafts repository. Ritu ============================================================================= Ritu Chadha Senior Scientist Telcordia Technologies (973) 829-4869 (voice) MCC 1J-218R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= --Flink_of_Cows_031_000 Content-Type: TEXT/plain; name="draft-chadha-policy-mpls-te-00.txt"; charset=US-ASCII; x-unix-mode=0664 Content-Description: draft-chadha-policy-mpls-te-00.txt Content-MD5: CN9K/f6K4q3CEppeDwXlDw== Content-Transfer-Encoding: QUOTED-PRINTABLE policy/mpls R. Chadha Internet Draft Huai-An (Paul) Lin Expires January 2001 Telcordia Technologies draft-chadha-policy-mpls-te-00.txt July 2000 Policy Information Model for MPLS Traffic Engineering Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract The purpose of this draft is to describe an information model for representing MPLS traffic engineering policies. RFC 2702, "Requirements for Traffic Engineering over MPLS", is used as a basis for determining the types of information that need to be represented in such an information model. The latter document describes the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. The information model described in this draft attempts to capture the information required to enable the functional capabilities described in RFC 2702. This information model could be used by a management system to optimize network performance through the necessary network provisioning actions. An overview of policy-based management is given in this document, along with a description of the relationship of this work to other information models that are being defined in the IETF Policy Framework working group. This is followed by a detailed description of the information model, and a number of examples illustrating its use. Chadha Expires January 2001 1 =0C Policy Information Model for MPLS Traffic Engineering July 2000 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. Introduction.....................................................3 1.1 Terminology....................................................3 1.2 Purpose of this document and Roadmap...........................4 2. Policy-Enabled MPLS Traffic Engineering..........................5 2.1 Relationship to previous work..................................5 2.2 Overview and Scope of this work................................6 3. Overview of MPLS Traffic Engineering Policy Data Model...........7 3.1 Overview of object classes and their associations..............7 3.2 High-level description of information model...................10 4. Detailed Description of MPLS Traffic Engineering Policy Information Model................................................................14 4.1 Object Class MPLSActivateTTAction.............................14 4.2 Object Class MPLSCreateLSPAction..............................16 4.3 Object Class MPLSDestroyLSPAction.............................16 4.4 Object Class MPLSDestroyTTAction..............................17 4.5 Object Class MPLSModifyTTAction...............................18 4.6 Object Class MPLSAssignLSPAction..............................18 4.7 Object Class MPLSDeassignLSPAction............................20 4.8 Object Class MPLSTrafficTrunk.................................21 4.9 Object Class MPLSRoute........................................25 4.10 Object Class MPLSLSP..........................................29 4.11 Object Class MPLSRouteSpec....................................31 4.12 Object Class MPLSResourceProfile..............................31 4.13 Object Class MPLSResources....................................33 4.14 The association MPLSHopInRoute................................35 4.15 The association MPLSASInRoute.................................36 4.16 The association MPLSSystemResources...........................37 4.17 The association MPLSEndpointResources.........................38 4.18 The association MPLSActiveConnection..........................38 4.19 The association MPLSReverseDirTT..............................40 4.20 The association MPLSEligibleRouteSpec.........................41 4.21 The association MPLSCurrentlyAssignedLSP......................42 4.22 The association MPLSBackupLSP.................................43 4.23 The association MPLSRouteResourceProfile......................44 4.24 The association MPLSRealizes..................................45 4.25 The association MPLSLSPinLSP..................................45 4.26 The association MPLSTrafficProfile............................46 5. Usage Examples..................................................47 5.1 Implementing Olympic Services.................................47 5.2 Creating traffic trunks.......................................54 5.3 Load balancing................................................57 5.4 Implementing Service Level Agreements (SLAs)..................57 6. Security Considerations.........................................58 7. Conclusions.....................................................58 8. References......................................................58 Chadha Expires January 2001 2 =0C Policy Information Model for MPLS Traffic Engineering July 2000 9. Acknowledgments.................................................60 10. Author's Addresses.............................................60 1. Introduction According to [3], Traffic Engineering (TE) is concerned with performance optimization of operational networks. In general, it encompasses the application of technology and scientific principles to the measurement, modeling, characterization, and control of Internet traffic, and the application of such knowledge and techniques to achieve specific performance objectives. The aspects of traffic engineering that are of interest for MPLS are measurement and control. A major goal of Internet traffic engineering is to facilitate efficient and reliable network operations while simultaneously optimizing network resource utilization and traffic performance. Traffic engineering has become an indispensable function in many large autonomous systems because of the high cost of network assets and the commercial and competitive nature of the Internet. These factors emphasize the need for maximal operational efficiency. The concept of MPLS traffic trunks is used extensively in the remainder of this document. According to Li and Rekhter [4], a traffic trunk is an aggregation of traffic flows of the same class which are placed inside a Label Switched Path. Essentially, a traffic trunk is an abstract representation of traffic to which specific characteristics can be associated. It is useful to view traffic trunks as objects that can be routed; that is, the path through which a traffic trunk traverses can be changed. In this respect, traffic trunks are similar to virtual circuits in ATM and Frame Relay networks. It is important, however, to emphasize that there is a fundamental distinction between a traffic trunk and the path, and indeed the LSP, through which it traverses. An LSP is a specification of the label switched path through which the traffic traverses. 1.1 Terminology The following abbreviations are used in this document: AS Autonomous System ATM Asynchronous Transfer Mode CIM Common Information Model CLI Command Line Interface COPS Common Open Policy Service DMTF Distributed Management Task Force FEC Forwarding Equivalence Class LDAP Lightweight Directory Access Protocol LSP Label Switched Path LSR Label Switched Router MAM Maximum Allocation Multiplier Chadha Expires January 2001 3 =0C Policy Information Model for MPLS Traffic Engineering July 2000 MIB Management Information Base MPLS Multi-Protocol Label Switching PCIM Policy Core Information Model PDP Policy Decision Point QoS Quality of Service QPIM QoS Policy Information Model SLA Service Level Agreement SNMP Simple Network Management Protocol TE Traffic Engineering WG Work Group 1.2 Purpose of this document and Roadmap This document presents an object-oriented information model for representing MPLS traffic engineering policy information. The model is based on the Policy Core Information Model [5] currently being jointly developed by the IETF Policy Framework WG and by the Distributed Management Task Force (DMTF) as part of the CIM (Common Information Model) extensions work. Our model defines two hierarchies of object classes: structural classes representing policy information and MPLS-specific objects referenced by these policies; and association classes that indicate how instances of the structural classes are related to each other. Subsequent documents will define mappings of this information model to various concrete implementations, for example, to a directory that uses LDAPv3 as its access protocol. The policy core information model is sufficiently generic to represent policies related to practically anything. Extensions of this model for representing QoS policies are being developed by the IETF Policy Framework WG [6]. The IETF IPSec Policy (ipsp) WG is also working on defining an information model for representing IPSec policies. This document derives object classes from the Policy Core Information Model and also makes use of some object classes from the QoS information model [6]. This document is organized in the following manner: - Section 2 describes the relationship of this work to previous work, provides a general overview of policies and how they are modeled. - Section 3 presents a high-level overview of the classes and associations comprising the Policy Information Model for MPLS Traffic Engineering. - Section 4 presents the detailed specifications for each of the object classes and associations in the data model. - Section 5 provides detailed examples illustrating the use of the Policy Information Model for MPLS Traffic Engineering. Chadha Expires January 2001 4 =0C Policy Information Model for MPLS Traffic Engineering July 2000 2. Policy-Enabled MPLS Traffic Engineering 2.1 Relationship to previous work As described in the Policy Core Information Model (PCIM) [5], policies can be regarded as rules with two basic components: conditions and actions. Conditions are boolean expressions which evaluate to either true or false. Actions represent some concrete action that should be taken by a management system if the conditions in the rule evaluate to true. The policy framework described in PCIM provides an elaborate mechanism for prioritizing policy rules; specifying time periods during which policy rules are applicable; specifying complex boolean conditions using either disjunctive normal form or conjunctive normal form and negations; grouping policies together; specifying reusable conditions and actions; etc. Policies are specified using a declarative rather than a procedural approach, i.e. policies describe the conditions and actions that make up a rule, but do not give a step-by-step description of how to implement the policy. In the QoS Policy Information Model (QPIM) [6], new object classes are defined to model the management and configuration of Diffserv- and RSVP-capable network elements. Apart from QoS-specific information, the model contains a number of concepts that are rather general and can be re-used in a number of different contexts. One such concept is that of variables and constants with well-defined semantics that represent things like IP addresses, port numbers, protocol numbers, etc. These variables are used to describe traffic classifiers in QPIM. Such a representation is also very useful for the information model described in this draft, as there is a need to define the FECs (Forwarding Equivalence Classes) that map to given traffic trunks. Other concepts that are re-used from QPIM are those defining traffic profiles and policing actions (see object classes qosPolicyPRTrfcProf and qosPolicyPRAction in [6]). These are used here for describing the traffic profiles of traffic trunks, and the policing requirements for traffic trunks (including what to do with non-conforming traffic for a given traffic trunk). Earlier Internet drafts ([13, 14]) discuss policy for MPLS. [13] outlines requirements for policy-enabled MPLS and identifies two main categories of MPLS policies: LSP admission policies that map traffic flows onto LSPs, and LSP life cycle policies that affect LSP creation, deletion, configuration and monitoring. The information model presented in the current draft addresses both these categories of policies, excluding any monitoring requirements. In [14], the authors discuss policies for MPLS load balancing. The information model that we present is broader in scope and addresses all aspects of traffic engineering, including load balancing. Chadha Expires January 2001 5 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The information model in this draft builds upon the PCIM model and further refines it by adding new actions that are specific to the domain of MPLS traffic engineering. Actions are included for creating, modifying, and destroying traffic trunks and LSPs, and assigning LSPs to traffic trunks. Also, new object classes and associations are introduced to model MPLS traffic engineering concepts referenced by these actions, such as traffic trunks, route specifications, LSPs and their hops, resources and resource classes, etc. No attempt is made to define new object classes for representing classifier information as this is currently being addressed in QPIM. 2.2 Overview and Scope of this work This information model presented in this draft has been designed to support the functionality outlined in RFC 2702 [3]. The latter document describes the following notions which have been modeled in this document: - Basic traffic engineering attributes of traffic trunks - Basic operations on traffic trunks - Traffic parameter attributes - Generic path selection and management attributes - Resource attributes. This information model currently does not cover modeling of LSP monitoring and operational attributes (such as LSP lifetime, error statistics, etc.). Further, this document does not seek to select mechanisms for performing MPLS traffic engineering; rather, it enables the specification of MPLS traffic engineering policies by defining an information model that attempts to capture the information required to describe such policies. Thus, even though MPLS supports traffic engineering via a number of mechanisms (CR- LDP, RSVP) that allow LSPs to be managed, such mechanisms are not referenced in this information model. This is in conformance with the requirement in [13] that an MPLS policy information model should be independent of the MPLS mechanisms used. The policy actions described in this draft enable the specification of actions that create, modify, and destroy traffic trunks and LSPs; and assign/de-assign LSPs to/from traffic trunks (object classes MPLSActivateTTAction, MPLSCreateLSPAction, MPLSDestroyLSPAction, MPLSDestroyTTAction, MPLSModifyTTAction, MPLSAssignLSPAction, and MPLSDeassignLSPAction). These actions reference and manipulate traffic trunks, LSPs, and related objects and associations. The idea is that a traffic engineering management system would be able to specify policies that result in the manipulation of traffic trunks, LSPs, and related information. The implementation of the policies would be performed by a PDP (Policy Decision Point) (see [7]). The PDP could make use of mechanisms supported by network elements to implement the specified policies; e.g. COPS, SNMP, CLI, etc. Several MIBs have been defined that could be used for implementing such Chadha Expires January 2001 6 =0C Policy Information Model for MPLS Traffic Engineering July 2000 policies, namely the MPLS Traffic Engineering MIB [8] and the MPLS LSR MIB [9], etc. 3. Overview of MPLS Traffic Engineering Policy Data Model 3.1 Overview of object classes and their associations The following figures show some of the new object classes and associations defined for the MPLS Traffic Engineering Policy Information Model. Some of these were briefly mentioned in the previous section. A number of object classes from previously defined information models, namely CIM [10] and QPIM [6], are also shown where necessary to illustrate new associations relating newly defined structural object classes to object classes previously defined in those information models. Object classes belonging to these information models are appropriately marked. A detailed description of the depicted object classes is provided in Section 4 of this document. +-----------------------------+ | qosPolicyPRTrfcProf (QPIM) | +-----------^-----------------+ 0..1| (a) | ---------- *| 0..1| | +-----------v---------v-+ | (b) | MPLSTrafficTrunk <------- | | 0..1 +-^-----------------^--^+ *| *| *| | | | (c) | (d)| |(e) | | | (f) | | | ---------- *| *| *| * | | +-----------------v-----+ * (g)* +-v--v-------------v----+ | | MPLSRouteSpec <---------> MPLSLSP <---- +-----------------------+ +-----------------------+ * Figure 1. Relationships between traffic trunks, LSPs, route specifications, and traffic profiles In Figures 1 and 2, boxes represent object classes and arrows represent associations between the classes. The following associations appear in Figure 1 above: (a) MPLSTrafficProfile (b) MPLSReverseDirTT (c) MPLSEligibleRouteSpec (d) MPLSCurrentlyAssignedLSP (e) MPLSBackupLSP Chadha Expires January 2001 7 =0C Policy Information Model for MPLS Traffic Engineering July 2000 (f) MPLSLSPinLSP (g) MPLSRealizes An association represents a relationship between two classes (e.g. associations (a), (c), (d), (e), and (g) above in Figure 1), or between a class and itself (e.g. associations (b) and (f) in Figure 1). Cardinalities are part of each association; the cardinality of an association indicates how many instances of each class may be related to an instance of the other class. For example, the MPLSBackupLSP association has the cardinality "*" (i.e. "0..n") for both the MPLSTrafficTrunk and the MPLSLSP classes. These ranges are interpreted as follows: - The "*" written next to MPLSTrafficTrunk indicates that an MPLSLSP may be related to no MPLSTrafficTrunk, to one MPLSTrafficTrunk, or to more than one MPLSTrafficTrunk via the MPLSBackupLSP association. In other words, an LSP may be a backup LSP for zero or more traffic trunks. - The "*" written next to MPLSLSP indicates that a MPLSTrafficTrunk may be related to no MPLSLSP, to one MPLSLSP, or to more than one MPLSLSP via the MPLSBackupLSP association. In other words, a traffic trunk may have zero or more backup LSPs. ----------- (h)| | *| | +----------------+ +---------------v--+ | |ComputerSystem | | ProtocolEndpoint <------| | (CIM) | | (CIM) |* +----------- ^---+ +^---------^-------+ *| *| *| (i)| (j)| (k)| 0..1| 0..1| *| +----v-----------v+ +-v------------+ | MPLSResources | | MPLSRoute | +-----------------+ +^----------^--+ *| *| (l)| (m)| *| 0..1| +----------------------v+ +----v----------------+ | AutonomousSystem (CIM)| | MPLSResourceProfile | +-----------------------+ +---------------------+ Figure 2. Relationships between routes, hops, resources, etc. The following associations appear in Figure 2 above: (h) MPLSActiveConnection (i) MPLSSystemResources (j) MPLSEndpointResources (k) MPLSHopInRoute (l) MPLSASInRoute Chadha Expires January 2001 8 =0C Policy Information Model for MPLS Traffic Engineering July 2000 (m) MPLSRouteResourceProfile The inheritance tree for the object classes defined in this document is given below. Apart from the new object classes defined in this document, the tree below contains references to object classes defined in the Policy Core Information Model [5], marked "PCIM" below, and to object classes defined in the Common Information Model [10], marked "CIM" below. For detailed descriptions of these object classes, please see the relevant documents. +--Policy (abstract) (PCIM) | | | +---PolicyAction (PCIM) | | | | | +---MPLSActivateTTAction | | | | | +---MPLSCreateLSPAction | | | | | +---MPLSDestroyLSPAction | | | | | +---MPLSDestroyTTAction | | | | | +---MPLSModifyTTAction | | | | | +---MPLSAssignLSPAction | | | | | +---MPLSDeassignLSPAction | | | +--- MPLSResourceProfile | +--CIM_ManagedSystemElement (abstract) (CIM) | +--CIM_LogicalElement (abstract) (CIM) | +--MPLSResources | +--MPLSTrafficTrunk | +--MPLSRoute (abstract) | +---MPLSRouteSpec | +---MPLSLSP Figure 3. Inheritance Hierarchy for MPLS Policy object classes In CIM, associations are also modeled as classes. For the MPLS Traffic Engineering Policy Information Model, the inheritance hierarchy is shown below: Chadha Expires January 2001 9 =0C Policy Information Model for MPLS Traffic Engineering July 2000 [unrooted] | +---MPLSHopInRoute | +---MPLSASInRoute | +---MPLSSystemResources | +---MPLSEndpointResources | +---ActiveConnection (CIM) | | | +---MPLSActiveConnection | +---MPLSReverseDirTT | +---MPLSEligibleRouteSpec | +---MPLSCurrentlyAssignedLSP | +---MPLSBackupLSP | +---MPLSRouteResourceProfile | +---MPLSRealizes | +---MPLSLSPinLSP | +---MPLSTrafficProfile Figure 4. Inheritance Hierarchy for associations 3.2 High-level description of information model 3.2.1 MPLS Traffic Engineering Policy Actions A number of policy actions are defined for the purpose of enabling a management system to manipulate traffic trunks and LSPs. These actions may reference instances of traffic trunks, LSPs, and route specifications (see definition of route specification in Section 3.2.2). In order to reference such instances, they must first be created and populated; and any related objects and associations must also be instantiated and populated. For example, MPLSActivateTTAction activates a traffic trunk; the property mpTrafficTrunk in this action references an instance of a traffic trunk that is to be activated. Thus before instantiating an instance of MPLSActivateTTAction, one must instantiate an instance of MPLSTrafficTrunk that will be referenced by this action. In addition, all the related object instances and associations must also be instantiated before instantiating this action. RFC 2702 [3] Chadha Expires January 2001 10 =0C Policy Information Model for MPLS Traffic Engineering July 2000 describes the difference between establishing a traffic trunk (which we model by creating an instance of MPLSTrafficTrunk and related classes as described in Section 3.2.1.1) and activating a traffic trunk (which is modeled by the MPLSActivateTTAction). 3.2.1.1 Referencing traffic trunks The following objects may need to be instantiated in order to fully describe a traffic trunk referenced by an action: - Route specifications: Zero or more route specifications (MPLSRouteSpec) can be associated with a traffic trunk to indicate that this is a potential route to which this traffic trunk can be mapped. The association is modeled by the MPLSEligibleRouteSpec association. - Traffic profile: A traffic profile (qosPolicyPRAction) describing the resource requirements of a traffic trunk can be defined for every traffic trunk and associated with the traffic trunk via the MPLSTrafficProfile association. - Assigned LSPs: Any LSPs (MPLSLSP) currently assigned to a traffic trunk can be defined and associated with it via the MPLSCurrentlyAssignedLSP association. - Backup LSPs: Any LSPs (MPLSLSP) that are acting as backup LSPs for a traffic trunk can be defined and associated with it via the MPLSBackupLSP association. - Reverse traffic trunk: If a traffic trunk carrying traffic in the reverse direction exists, it can be associated with a given traffic trunk via the MPLSReverseDirTT association. 3.2.1.2 Referencing LSPs The following objects may need to be instantiated in order to fully describe an LSP referenced by an action: - Route specifications: Zero or more route specifications (MPLSRouteSpec) can be associated with an LSP to indicate that this LSP is an realization of the route specification. The association is modeled by the MPLSRealizes association. - Traffic trunks: Any traffic trunks (MPLSTrafficTrunk) whose traffic is currently being carried by an LSP should be defined and associated with this LSP via the MPLSCurrentlyAssignedLSP association. Further, any traffic trunks for which an LSP is a backup LSP should be associated with this LSP via the MPLSBackupLSP association. Chadha Expires January 2001 11 =0C Policy Information Model for MPLS Traffic Engineering July 2000 - LSP hierarchy: If a hierarchy of LSPs exists, an LSP should be associated with any LSPs contained in or containing it via the MPLSLSPinLSP association. - Resource profile: A resource profile (MPLSResourceProfile) describing the resource profile of an LSP can be defined for every LSP and associated with it via the MPLSRouteResourceProfile association. - Route hops: Every known hop in an LSP is represented by an instance of ProtocolEndpoint (from the CIM information model; see [10]) and is associated with an LSP via the MPLSHopInRoute association. - Autonomous systems in LSP path: If the path of an LSP through an external autonomous system is unknown, this autonomous system is represented by an instance of AutonomousSystem (from the CIM information model; see [10]) and is associated with an LSP via the MPLSASInRoute association. 3.2.1.3 Referencing route specifications The following objects may need to be instantiated in order to fully describe a route specification referenced by an action: - LSPs: Zero or more LSPs (MPLSLSP) can be associated with a route specification to indicate that these LSPs are realizations of the route specification. The association is modeled by the MPLSRealizes association. - Traffic trunks: Traffic trunks (MPLSTrafficTrunk) for which a given route specification is a potential route should be associated with the route specification via the MPLSEligibleRouteSpec association. - Resource profile: A resource profile (MPLSResourceProfile) describing the resource profile of a route specification can be defined for every route specification and associated with it via the MPLSRouteResourceProfile association. - Route hops: Every hop specified for a route specification is represented by an instance of ProtocolEndpoint (from the CIM information model; see [10]) and is associated with a route specification via the MPLSHopInRoute association. - Autonomous systems in route path: If a route specification is to be routed via an specified autonomous sytem, this autonomous system is represented by an instance of AutonomousSystem (from the CIM information model; see [10]) and is associated with a route specification via the MPLSASInRoute association. Chadha Expires January 2001 12 =0C Policy Information Model for MPLS Traffic Engineering July 2000 3.2.2 Traffic trunks, LSPs, and supporting object classes and associations The following object classes and associations are defined. Many of these are referenced by the actions described in the previous section. - Traffic trunk (object class MPLSTrafficTrunk): For a description of a traffic trunk, see the Introduction section of this document, or see RFC 2702 [3] for more details. The attributes of a traffic trunk are described by the properties of this object class. A traffic trunk can be associated with LSPs that are currently carrying its traffic (MPLSCurrentlyAssignedLSP association) and with backup LSPs that are used for backup in fault/congestion scenarios (MPLSBackupLSP association). Eligible routes for this traffic trunk are associated with it via the MPLSEligibleRouteSpec association. If a traffic trunk going in the reverse direction exists, it is associated with this traffic trunk via the MPLSReverseDirTT association. Finally, a traffic profile for this traffic trunk can be represented by the qosPolicyPRTrfcProf object class (reused from QPIM [6]) and associated with the traffic trunk via the MPLSTrafficProfile association. - Abstract route (object class MPLSRoute): This is an abstract object class that represents a route from point A to point B. The route may or may not be realized in the network by an LSP. In other words, a route could either be a specification of a route from one point to another, or it could be an actual LSP that has been set up in the network. A route is associated with all the hops contained in this route. These hops could either be interfaces on LSRs (represented by instances of ProtocolEndpoint, which is an object class defined in the CIM Network Model [10]), or they could be autonomous systems (represented by instances of AutonomousSystem, another object class defined in the CIM Network Model [10]). The associations with these hops are realized via the MPLSHopInRoute and MPLSASInRoute associations, respectively. A route may also be associated with a resource profile (represented by object class MPLSResourceProfile, defined in this draft) which describes the resource profile for this route, i.e. the allowable traffic rates and burst sizes, etc. (MPLSRouteResourceProfile association). - Route specification (object class MPLSRouteSpec): This object class is used to describe a specification of a route from one node to another and is derived from the MPLSRoute object class described above. The difference between an MPLSRouteSpec and an MPLSLSP is that the former is not necessarily a physically created LSP; rather, it is a specification of a route that could be used by a management system to create an actual LSP (for rerouting or backup purposes). Also note that it could be an incomplete specification of a route; e.g. it could specify three hops for a route which actually requires at least four hops, and leave the job of choosing the missing hop to a signaling protocol that sets up the corresponding LSP. Its properties are inherited from MPLSRoute and are a subset of the Chadha Expires January 2001 13 =0C Policy Information Model for MPLS Traffic Engineering July 2000 properties in MPLSLSP. An LSP can be created based on a route specification using the MPLSCreateLSPAction. The typical use of this object class is for a network operator to be able to specify potential MPLS routes in advance and later instantiate them by creating LSPs that use this specification. A route specification can be associated with a traffic trunk to indicate that this is a potential route to which this traffic trunk can be mapped (MPLSEligibleRouteSpec association). - Label-Switched Path (LSP) (object class MPLSLSP): This object class represents an LSP. An LSP can be associated with a route specification in order to indicate that this LSP implements this route specification (MPLSRealizes association). An LSP can also be associated with a traffic trunk if it is currently carrying the traffic for this traffic trunk (via the MPLSCurrentlyAssignedLSP association) or if it is a backup LSP for this traffic trunk (via the MPLSBackupLSP association). An LSP can also be associated with another LSP to indicate a hierarchy of LSPs (MPLSLSPinLSP association). - Resource profile (object class MPLSResourceProfile): This object class represents the resource profile associated with a route, i.e. the allowable traffic rates and burst sizes, etc. - Resources (object class MPLSResources): This object class represents resources associated with LSRs and interfaces on these LSRs, such as buffer resources, etc. (MPLSSystemResources and MPLSEndpointResources associations, respectively). - Links and their resources (association MPLSActiveConnection): The resources associated with a link (e.g. bandwidth, etc.) are represented by properties of the association MPLSActiveConnection. This association is used to relate two instances of ProtocolEndpoint that currently have an active connection between them. Apart from these newly defined object classes and associations, the qosPolicyPRAction object class is reused from QPIM [6] for representing policing actions including actions to be taken for non- conforming traffic. Also, object classes qosPolicySimpleCondition, qosPolicyVariable, and qosPolicyValue and their derived classes from QPIM are used for representing classifier information. 4. Detailed Description of MPLS Traffic Engineering Policy Information Model This section provides a detailed description of all the newly defined object classes and associations in this information model, along with their properties. 4.1 Object Class MPLSActivateTTAction Chadha Expires January 2001 14 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This object class represents a policy action (see [5]) that creates an instance of a traffic trunk by assigning it to a traffic flow (referred to as "activation" of a traffic trunk in [3]). Note that a traffic trunk must first be established or defined by creating an instance of MPLSTrafficTrunk and related objects/associations (see Section 3.2.1.1 for details). RFC 2702 [3] describes the difference between establishing a traffic trunk (which we model by creating an instance of MPLSTrafficTrunk and related classes as described in Section 3.2.1.1) and activating a traffic trunk (which is modeled by the MPLSActivateTTAction). The class definition is as follows: NAME MPLSActivateTTAction DESCRIPTION A class used to describe a policy action that activates a traffic trunk. DERIVED FROM policyAction (defined in [5]) ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk 4.1.1 The property Name Name of the action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string =20 4.1.2 The property mpTrafficTrunk This property contains a reference to an instance of MPLSTrafficTrunk. The semantics are that this policy action assigns the traffic described in the condition portion of the corresponding policy rule to this traffic trunk. The condition portion of the containing policy rule would describe the FECs that are mapped to this traffic trunk by using instances of qosPolicySimpleCondition (from QPIM [6]). Note that the instance of MPLSTrafficTrunk that is referenced can be re-used as it can be referenced by multiple policy actions. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Traffic trunk associated with traffic described in the policy rule to which this action belongs SYNTAX Reference to an MPLSTrafficTrunk Chadha Expires January 2001 15 =0C Policy Information Model for MPLS Traffic Engineering July 2000 4.2 Object Class MPLSCreateLSPAction This class is used to create an LSP. Note that a route specification must first be defined by creating an instance of MPLSRouteSpec and related objects/associations (see Section 3.2.1.3 for details). NAME MPLSCreateLSPAction DESCRIPTION A class that represents an action that creates an MPLS LSP. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpCreateLSP 4.2.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action SYNTAX string =20 4.2.2 The property mpCreateLSP This property contains a reference to an MPLSRouteSpec according to whose specifications an LSP is to be created. The property definition is as follows: NAME mpCreateLSP DESCRIPTION Specification of LSP to be created SYNTAX Reference to an instance of MPLSRouteSpec =20 4.3 Object Class MPLSDestroyLSPAction This class is used to represent the action of tearing down an LSP and reclaiming all the resources allocated to it. NAME MPLSDestroyLSPAction DESCRIPTION A class that represents an action that destroys an LSP. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpLSP 4.3.1 The property Name Chadha Expires January 2001 16 =0C Policy Information Model for MPLS Traffic Engineering July 2000 Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.3.2 The property mpLSP This property is a reference to the instance of MPLSLSP that is to be torn down. The property definition is as follows: NAME mpLSP DESCRIPTION Reference to LSP being destroyed. SYNTAX Reference to an instance of MPLSLSP 4.4 Object Class MPLSDestroyTTAction This class is used to represent the action of tearing down a traffic trunk and reclaiming all the resources allocated to it. This does not mean that the LSP(s) assigned to this trunk will be torn down; rather, such LSPs will have more resources available for carrying alternate traffic. NAME MPLSDestroyTTAction DESCRIPTION A class that represents an action that destroys a traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk 4.4.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.4.2 The property mpTrafficTrunk Chadha Expires January 2001 17 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This property is a reference to the instance of MPLSTrafficTrunk that is to be torn down. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Reference to traffic trunk being destroyed. SYNTAX Reference to an instance of MPLSTrafficTrunk 4.5 Object Class MPLSModifyTTAction This class is used to modify a traffic trunk. Note that the traffic trunk is assumed to have been defined by creating an instance of MPLSTrafficTrunk and related objects/associations (see Section 3.2.1.1 for details). NAME MPLSModifyTTAction DESCRIPTION A class that represents an action that modifies an MPLS traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk 4.5.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action SYNTAX string =20 4.5.2 The property mpTrafficTrunk This property contains a reference to an MPLSTrafficTrunk that is to be modified. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Reference to traffic trunk to be modified SYNTAX Reference to an instance of MPLSTrafficTrunk 4.6 Object Class MPLSAssignLSPAction This class is used to represent the action of assigning an LSP to a traffic trunk. Note that the traffic trunk and LSP are assumed to Chadha Expires January 2001 18 =0C Policy Information Model for MPLS Traffic Engineering July 2000 have been defined by creating instances of MPLSTrafficTrunk and MPLSLSP, respectively, as well as related objects/associations (see Sections 3.2.1.1 and 3.2.1.2 for details). NAME MPLSAssignLSPAction DESCRIPTION A class that represents an action that assigns an LSP to a traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk mpAssignedLSP 4.6.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.6.2 The property mpTrafficTrunk This property contains a reference to an instance of MPLSTrafficTrunk. Note that the instance of MPLSTrafficTrunk that is referenced can be re-used as it can be referenced by multiple policy actions. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Traffic trunk to which an LSP is being assigned SYNTAX Reference to an MPLSTrafficTrunk 4.6.3 The property mpAssignedLSP This property is a reference to an instance of MPLSLSP. The semantics here are that the traffic trunk referenced within this action is to be sent over the referenced LSP. The property definition is as follows: NAME mpAssignedLSP DESCRIPTION Reference to LSP being assigned to a traffic trunk SYNTAX Reference to an instance of MPLSLSP Chadha Expires January 2001 19 =0C Policy Information Model for MPLS Traffic Engineering July 2000 4.7 Object Class MPLSDeassignLSPAction This class is used to represent the action of de-assigning an LSP from a traffic trunk, i.e. if the traffic belonging to a traffic trunk was being sent over a given LSP, this action stops any further traffic from this traffic trunk from being sent over this LSP. Note that the traffic trunk and LSP are assumed to have been defined by creating instances of MPLSTrafficTrunk and MPLSLSP, respectively, as well as related objects/associations (see Sections 3.2.1.1 and 3.2.1.2 for details). NAME MPLSDeassignLSPAction DESCRIPTION A class that represents an action that de-assigns an LSP from a traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk mpDeassignedLSP 4.7.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.7.2 The property mpTrafficTrunk This property contains a reference to an instance of MPLSTrafficTrunk. Note that the instance of MPLSTrafficTrunk that is referenced can be re-used as it can be referenced by multiple policy actions. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Traffic trunk for which an LSP is being de-assigned SYNTAX Reference to an MPLSTrafficTrunk 4.7.3 The property mpDeassignedLSP This property is a reference to an instance of MPLSLSP. The semantics here are that the traffic trunk referenced within this Chadha Expires January 2001 20 =0C Policy Information Model for MPLS Traffic Engineering July 2000 action is assumed to be currently transported by the referenced LSP and is no longer to be sent over this LSP. The property definition is as follows: NAME mpDeassignedLSP DESCRIPTION Reference to LSP being de-assigned from a traffic trunk SYNTAX Reference to an instance of MPLSLSP 4.8 Object Class MPLSTrafficTrunk This object class is used to represent an MPLS traffic trunk and its properties. A traffic trunk is an aggregation of traffic flows of the same class which are placed inside an LSP (or more than one LSPs, in the case of load balancing). Essentially, a traffic trunk is an abstract representation of traffic to which specific characteristics can be associated. This class contains properties describing attributes that can be associated with traffic trunks to influence their behavioral characteristics. Several of these attributes are drawn from RFC 2702 [3]. The class definition is as follows: NAME MPLSTrafficTrunk DESCRIPTION A class with several properties for describing an MPLS traffic trunk. DERIVED FROM LogicalElement ABSTRACT FALSE PROPERTIES Name mpResourceClassAffinity mpPreemption mpPriority mpResilience mpTrafficProportion mpReoptimizationFreq 4.8.1 The property Name Name for this traffic trunk. The property definition is as follows: NAME Name DESCRIPTION Name for this traffic trunk. SYNTAX string 4.8.2 The property mpResourceClassAffinity Chadha Expires January 2001 21 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This property represents the resource class affinity attributes (see [3]) associated with a traffic trunk which can be used to specify the class of resources that are to be explicitly included or excluded from the path of the traffic trunk (the property mpResourceClass, which appears in object class MPLSResources and in association MPLSActiveConnection, describes the "class" that a resource belongs to). The mpResourceClassAffinity property contains a list of policy attributes which can be used to impose additional constraints on the path traversed by a given traffic trunk. The resource class affinity property for a traffic trunk contains a string of the form: The "resource-class" parameter in the above identifies a resource class for which an affinity relationship is defined with respect to the traffic trunk. The "affinity" parameter above is a boolean value that indicates the affinity relationship; that is, whether members of the resource class are to be included or excluded from the path of the traffic trunk. The value "true" signifies explicit inclusion, and the value "false" specifies explicit exclusion. If no resource class affinity attributes are specified, then a "don't care" affinity relationship is assumed to hold between the traffic trunk and all resources. That is, there is no requirement to explicitly include or exclude any resources from the traffic trunk's path. This should be the default in practice. Resource class affinity attributes are very useful and powerful constructs because they can be used to implement a variety of policies. For example, they can be used to contain certain traffic trunks within specific topological regions of the network. A "constraint-based routing" framework (see [3]) can be used to compute an LSP for a traffic trunk subject to resource class affinity constraints in the following manner: 1. For explicit inclusion, prune all resources not belonging to the specified classes before performing LSP computation. 2. For explicit exclusion, prune all resources belonging to the specified classes before performing LSP computation. The property definition is as follows: NAME mpResourceClassAffinity DESCRIPTION String containing resource class affinities SYNTAX string 4.8.3 The property mpPreemption Chadha Expires January 2001 22 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The preemption attribute (see [3]) determines whether a traffic trunk can preempt another traffic trunk from a given path, and whether it can be preempted by another traffic trunk. Preemption can used to assure that high priority traffic trunks can always be routed through relatively favorable paths within a differentiated services environment. Preemption can also be used to implement various prioritized restoration policies following fault events. The preemption property can take one of four values, with the following semantics: 1. preemptor-enabled: can preempt lower priority preemptable traffic trunks 2. non-preemptor: cannot preempt other traffic trunks 3. preemptable: can be preempted by higher priority preemptor- enabled traffic trunks 4. non-preemptable: cannot be preempted. It is trivial to see that some of the preempt modes are mutually exclusive. Using the numbering scheme depicted above, the feasible preempt mode combinations for a given traffic trunk are as follows: (1, 3), (1, 4), (2, 3), and (2, 4). The (2, 4) combination should be the default. A traffic trunk, say "A", can preempt another traffic trunk, say "B", only if *all* of the following five conditions hold: 1. "A" has a relatively higher priority than "B" 2. "A" contends for a resource utilized by "B" 3. The resource cannot concurrently accommodate "A" and "B" based on certain decision criteria 4. "A" is preemptor enabled 5. "B" is preemptable. Preemption is not considered a mandatory attribute under the current best effort Internet service model, although it may be useful. However, in a differentiated services scenario, the need for preemption becomes more compelling. Moreover, in the emerging optical internetworking architectures, where some protection and restoration functions may be migrated from the optical layer to data network elements (such as gigabit and terabit label switching routers) to reduce costs, preemptive strategies can be used to reduce the restoration time for high priority traffic trunks under fault conditions. The property definition is as follows: NAME mpPreemption DESCRIPTION Contains preemptability information SYNTAX uint16[] (values from 1 to 4) 4.8.4 The property mpPriority Chadha Expires January 2001 23 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The priority of a traffic trunk is described by this property. The priority property defines the relative importance of traffic trunks. If a constraint-based routing framework is used with MPLS, priorities can be used to determine the order in which path selection is done for traffic trunks at connection establishment and under fault scenarios. Priorities are also important in implementations permitting preemption because they can be used to impose a partial order on the set of traffic trunks according to which preemptive policies can be applied. The priority of a traffic trunk, along with its preemptability information (see the description of the mpPreemption property in the previous section), determines when it will preempt and/or be preempted by other traffic trunks. The property definition is as follows: NAME mpPriority DESCRIPTION Priority for this traffic trunk. SYNTAX uint16 4.8.5 The property mpResilience The mpResilience property indicates the recovery procedure to be applied to traffic trunks whose paths are impacted by faults. More specifically, it contains a boolean value that determines whether the target traffic trunk is to be rerouted or not when segments of its path fail. Note that RFC 2702 [3] discusses extended resilience attributes that could be used to specify detailed actions to be taken when faults occur. The representation of such attributes is left for further study. The property definition is as follows: NAME mpResilience DESCRIPTION If set to true, this traffic trunk should be rerouted in case of failure; if false, it should not. SYNTAX boolean 4.8.6 The property mpTrafficProportion This property is used to indicate the relative proportion of traffic to be carried by parallel traffic trunks. This enables one to perform load distribution across multiple parallel traffic trunks between two nodes. In many practical situations, the aggregate traffic between two nodes may be such that no single link can carry the load. In this case, the only feasible solution is to appropriately divide the aggregate traffic into sub-streams and route the sub-streams through multiple paths between the two nodes. Chadha Expires January 2001 24 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This problem can be addressed by instantiating multiple traffic trunks between the two nodes, such that each traffic trunk carries a proportion of the aggregate traffic. The proportion of traffic carried by each such trunk is specified by the mpTrafficProportion property. The property definition is as follows: NAME mpTrafficProportion DESCRIPTION Proportion of traffic to be carried by this traffic trunk, specified as a percentage from 0 to 100. SYNTAX uint16 4.8.7 The property mpReoptimizationFreq Due to changes in network and traffic characteristics, there may be a need to periodically change the paths of traffic trunks for optimization purposes. This should not be done too frequently as this could adversely affect the stability of the network. This property indicates how often such reoptimization should be performed. The property definition is as follows: NAME mpReoptimizationFreq DESCRIPTION Indicates how frequently reoptimization should be performed for this traffic trunk. If the value of this property is set to zero, this indicates that reoptimization should not be performed. SYNTAX uint16 4.9 Object Class MPLSRoute This object class is used to represent an MPLS route and its properties. An MPLS route is an abstract class with two structural subclasses, MPLSRouteSpec and MPLSLSP, representing a specification of an MPLS route or a concrete LSP respectively. Some of the properties of this class have been drawn from the mplsTunnelTable in the MPLS Traffic Engineering MIB [8]. The class definition is as follows: NAME MPLSRoute DESCRIPTION A class with several properties for describing an MPLS route. DERIVED FROM LogicalElement ABSTRACT true PROPERTIES Name mpIngressIPAddress mpEgressIPAddress Chadha Expires January 2001 25 =0C Policy Information Model for MPLS Traffic Engineering July 2000 mpCOS mpSignalingProtocol mpSetupPriority mpHoldingPriority mpIngressMayReroute mpIsPersistent mpLocalProtectionAvailable mpIsPinned mpOwner mpInstancePriority mpIsAdaptive mpPreference 4.9.1 The property Name The canonical name assigned to the MPLS route. The property definition is as follows: NAME Name DESCRIPTION MPLS route name SYNTAX string 4.9.2 The property mpIngressIPAddress Ingress IP address for this MPLS route. The property definition is as follows: NAME mpIngressIPAddress DESCRIPTION Ingress IP address for this MPLS route. SYNTAX string =20 4.9.3 The property mpEgressIPAddress Egress IP address for this MPLS route. The property definition is as follows: NAME mpEgressIPAddress DESCRIPTION Egress IP address for this MPLS route. SYNTAX string =20 4.9.4 The property mpCOS This property defines the class of service for this MPLS route. This class of service could represent either a DSCP value or a ToS value. Further refinement of this property definition is for further study. Chadha Expires January 2001 26 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The property definition is as follows: NAME mpCOS DESCRIPTION Class of service for MPLS route SYNTAX uint16 DEFAULT VALUE 0 4.9.5 The property mpSignalingProtocol The signaling protocol, if any, used or to be used to set up this MPLS route. The property definition is as follows: NAME mpSignalingProtocol DESCRIPTION Signaling protocol used or to be used to set up this MPLS route. SYNTAX uint16 VALUES none(1), ldp(2), rsvp(3), other(4) =20 4.9.6 The property mpSetupPriority Indicates the setup priority of this MPLS route (see [11] and [12]). The property definition is as follows: NAME mpSetupPriority DESCRIPTION Indicates the setup priority of this MPLS route. SYNTAX uint16 =20 4.9.7 The property mpHoldingPriority Indicates the holding priority for this MPLS route (see [11] and [12]). The property definition is as follows: NAME mpHoldingPriority DESCRIPTION Holding priority for this MPLS route SYNTAX uint16 =20 4.9.8 The property mpIngressMayReroute This flag indicates that the MPLS route ingress node may choose to reroute this MPLS route without tearing it down. The property definition is as follows: Chadha Expires January 2001 27 =0C Policy Information Model for MPLS Traffic Engineering July 2000 NAME mpIngressMayReroute DESCRIPTION Fast reroute enabled SYNTAX boolean 4.9.9 The property mpIsPersistent Indicates whether this MPLS route should be restored automatically after a failure occurs. The property definition is as follows: NAME mpIsPersistent DESCRIPTION Indicates whether this MPLS route is persistent or not SYNTAX boolean =20 4.9.10 The property mpLocalProtectionAvailable This flag permits transit routers to use a local repair mechanism which may result in violation of the explicit routing of this MPLS route. When a fault is detected on an adjacent downstream link or node, a transit router can reroute traffic for fast service restoration. The property definition is as follows: NAME mpLocalProtectionAvailable DESCRIPTION Indicates whether local protection is available SYNTAX boolean =20 4.9.11 The property mpIsPinned This flag indicates whether the loose-routed hops of this MPLS route are to be pinned (see [11]). The property definition is as follows: NAME mpIsPinned DESCRIPTION Indicates whether the route is pinned SYNTAX boolean =20 4.9.12 The property mpOwner Indicates which protocol created/should create this route and is/should be responsible for managing it. The property definition is as follows: Chadha Expires January 2001 28 =0C Policy Information Model for MPLS Traffic Engineering July 2000 NAME mpOwner DESCRIPTION Indicates which protocol created/should create this route and is/should be responsible for managing it. SYNTAX uint16 VALUES snmp (1), ldp (2), rsvp (3),policyAgent (4), other (5) 4.9.13 The property mpInstancePriority This value indicates the priority for this route, with zero indicating the lowest priority. The property definition is as follows: NAME mpInstancePriority DESCRIPTION Route Priority SYNTAX uint16 =20 4.9.14 The property mpIsAdaptive An MPLS route might need to re-route itself (e.g. due to re- optimization, connectivity problems, increase in bandwidth, etc.). If an MPLS route is configured to be adaptive, it (a) maintains existing resources until a new path is set up (b) avoids double-counting for links shared by the old and new paths. The property definition is as follows: NAME mpIsAdaptive DESCRIPTION A boolean indicating whether an MPLS route is adaptive or not. SYNTAX boolean DEFAULT VALUE true 4.9.15 The property mpPreference Multiple MPLS routes may exist between ingress and egress routers; the MPLS route with the lowest preference is used (useful for load balancing). The property definition is as follows: NAME mpPreference DESCRIPTION Preference assigned to an MPLS route. SYNTAX uint16 4.10 Object Class MPLSLSP Chadha Expires January 2001 29 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This object class is used to represent an MPLS LSP and its properties. Instances of this class represent existing LSPs in the network. The class definition is as follows: NAME MPLSLSP DESCRIPTION A class with several properties for describing an MPLS LSP. DERIVED FROM MPLSRoute ABSTRACT FALSE PROPERTIES Name mpAdminStatus mpOperationalStatus mpLevel 4.10.1 The property Name This is the canonical name assigned to the LSP. The name may be the tunnel ID or may be the name used to refer to the LSP on the LSR's console port (see the definition of mplsTunnelName in [8]). This definition may need further refinement in subsequent versions of this document. The property definition is as follows: NAME Name DESCRIPTION Name for this LSP. SYNTAX string 4.10.2 The property mpAdminStatus This property indicates the desired operational status of this LSP. The property definition is as follows: NAME mpAdminStatus DESCRIPTION Administrative status of an LSP. SYNTAX uint16 VALUES up(1), down(2), testing(3) 4.10.3 The property mpOperationalStatus This property indicates the actual operational status of this LSP, which is typically (but is not limited to) a function of the state of individual segments of this LSP. The property definition is as follows: NAME mpOperationalStatus DESCRIPTION Operational status of an LSP. Chadha Expires January 2001 30 =0C Policy Information Model for MPLS Traffic Engineering July 2000 SYNTAX uint16 VALUES up(1), down(2), testing(3), unknown(4), dormant(5), notPresent(6), lowerLayerDown(7) 4.10.4 The property mpLevel This property indicates the nesting level of this LSP. The property definition is as follows: NAME mpLevel DESCRIPTION LSP nesting level. SYNTAX uint16 4.11 Object Class MPLSRouteSpec This object class is used to represent a specification of a potential path for routing an MPLS traffic trunk. The difference between an MPLSRouteSpec and an MPLSLSP is that the former is not necessarily a physically created LSP; rather, it is a specification of a route that could be used by a management system to create an actual LSP (for rerouting or backup purposes). Its properties are inherited from MPLSRoute and are a subset of the properties in MPLSLSP. An LSP can be created based on a route specification using the MPLSCreateLSPAction. The class definition is as follows: NAME MPLSRouteSpec DESCRIPTION A class describing an MPLS route specification. DERIVED FROM MPLSRoute ABSTRACT FALSE 4.12 Object Class MPLSResourceProfile This object class describes bandwidth resources required or used by an MPLS route (recall that an MPLS route is an abstract class and can be instantiated either as an MPLS LSP or as an MPLS route specification). The properties describing these resources form a resource profile and different LSPs/route specifications with the same resource profile can reuse the same instance of this object class via the MPLSRouteResourceProfile association. The properties of this object class are derived from the mplsTunnelResourceTable in the MPLS TE MIB [8]. The class definition is as follows: NAME MPLSResourceProfile DESCRIPTION A class with several properties for Chadha Expires January 2001 31 =0C Policy Information Model for MPLS Traffic Engineering July 2000 describing resources required or used by zero or more MPLS LSPs and/or route specifications. DERIVED FROM Policy ABSTRACT FALSE PROPERTIES Name mpInMaxRate mpInMeanRate mpInMaxBurstSize mpOutMaxrate mpOutMeanRate mpOutMaxBurstSize 4.12.1 The property Name Name of this resource profile. The property definition is as follows: NAME Name DESCRIPTION Name of this resource profile. SYNTAX string =20 4.12.2 The property mpInMaxRate The maximum incoming rate in bits/second. Note that setting mpInMaxRate, mpInMeanRate, and mpInMaxBurstSize to 0 indicates best- effort treatment. The property definition is as follows: NAME mpInMaxRate DESCRIPTION Maximum incoming rate in bits/second. SYNTAX uint16 =20 4.12.3 The property mpInMeanRate The mean incoming rate in bits/second. The property definition is as follows: NAME mpInMeanRate DESCRIPTION Mean incoming rate in bits/second. SYNTAX uint16 =20 4.12.4 The property mpInMaxBurstSize The maximum burst size in bytes. The property definition is as follows: Chadha Expires January 2001 32 =0C Policy Information Model for MPLS Traffic Engineering July 2000 NAME mpInMaxBurstSize DESCRIPTION The maximum burst size in bytes. SYNTAX uint16 =20 4.12.5 The property mpOutMaxrate The maximum outgoing rate in bits/second. Note that setting mpOutMaxRate to 0 indicates best-effort treatment. The property definition is as follows: NAME mpOutMaxrate DESCRIPTION The maximum outgoing rate in bits/second. SYNTAX uint16 =20 4.12.6 The property mpOutMeanRate The mean outgoing rate in bits/second. The property definition is as follows: NAME mpOutMeanRate DESCRIPTION The mean outgoing rate in bits/second. SYNTAX uint16 =20 4.12.7 The property mpOutMaxBurstSize The maximum outgoing burst size in bytes. The property definition is as follows: NAME mpOutMaxBurstSize DESCRIPTION The maximum outgoing burst size in bytes. SYNTAX uint16 4.13 Object Class MPLSResources This class represents resources associated with LSRs and with interfaces on LSRs. The resources described by this class are associated with the corresponding LSRs/interfaces via the MPLSSystemResources and the MPLSEndpointResources associations, respectively. The class definition is as follows: NAME MPLSResources DESCRIPTION Resources associated with LSRs and their interfaces Chadha Expires January 2001 33 =0C Policy Information Model for MPLS Traffic Engineering July 2000 ABSTRACT false DERIVED FROM LogicalElement PROPERTIES Name mpBufferResources mpMaxAllocMultiplier mpResourceClass 4.13.1 The property Name Name for this set of resources. The property definition is as follows: NAME Name DESCRIPTION Name for this set of resources SYNTAX string 4.13.2 The property mpBufferResources Buffer resources for an LSR or an LSR interface. The property definition is as follows: NAME mpBufferResources DESCRIPTION Buffer resources. SYNTAX uint16 4.13.3 The property mpMaxAllocMultiplier The maximum allocation multiplier (MAM) (see [3]) of a resource determines the proportion of the resource that is available for allocation to traffic trunks. This attribute is applicable to buffer resources on LSRs. The value of the MAM can be chosen so that a resource can be under-allocated or over-allocated. A resource is said to be under-allocated if the aggregate demands of all traffic trunks that can be allocated to it are always less than the capacity of the resource. A resource is said to be over-allocated if the aggregate demands of all traffic trunks allocated to it can exceed the capacity of the resource. The property definition is as follows: NAME mpMaxAllocMultiplier DESCRIPTION Proportion of buffer resources that are available for allocation to traffic trunks. SYNTAX uint16 4.13.4 The property mpResourceClass Chadha Expires January 2001 34 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This property describes the "class" that a resource belongs to (see [3]). Thus a resource class can be viewed as a "color" assigned to a resource such that the set of resources with the same "color" conceptually belongs to the same class. Resource classes can be used to implement a variety of policies. From a Traffic Engineering perspective, they can be used to implement many policies with regard to both traffic and resource oriented performance optimization. For example, resource class attributes can be used to apply uniform policies to a set of resources; specify the relative preference of sets of resources for path placement of traffic trunks; explicitly restrict the placement of traffic trunks to specific subsets of resources; etc. In general, a resource can be assigned more than one resource class attribute. For example, all of the OC-48 links in a given network may be assigned a distinguished resource class attribute. The subsets of OC-48 links which exist within a given domain of the network may be assigned additional resource class attributes in order to implement specific containment policies, or to architect the network in a certain manner. The property definition is as follows: NAME mpResourceClass DESCRIPTION Resource class(es) that a resource belongs to. SYNTAX uint16[] 4.14 The association MPLSHopInRoute The association MPLSHopInRoute provides a way to associate hops with MPLSRoutes. Hops are instances of ProtocolEndpoint (from the CIM model [10]) and represent LSR interfaces. The association definition is as follows: NAME MPLSHopInRoute DESCRIPTION Associates hops with MPLSRoutes ABSTRACT false PROPERTIES mpRoute[ref MPLSRoute[0..n]] mpHop[ref ProtocolEndpoint[0..n]] mpIsStrict mpOrder 4.14.1 The reference mpRoute =20 This property contains an object reference to an MPLSRoute with which a number of hops can be associated. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRoutes associated with any given hop, indicating that this hop is contained in all these routes. 4.14.2 The reference mpHop =20 Chadha Expires January 2001 35 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This property contains an object reference to a ProtocolEndpoint (representing an LSR interface) that is a hop for an MPLSRoute. The [0..n] cardinality indicates that there may be 0, 1, or more than one hops associated with any given MPLSRoute. These are all the hops that are included in the route specification. 4.14.3 The property mpIsStrict Denotes whether the referenced hop is routed in a strict or loose fashion. The property definition is as follows: NAME mpIsStrict DESCRIPTION Denotes whether the referenced hop is routed in a strict or loose fashion. SYNTAX boolean =20 4.14.4 The property mpOrder This property indicates the hop sequence, 1..n. The property definition is as follows: NAME mpOrder DESCRIPTION Hop sequence SYNTAX uint16 4.15 The association MPLSASInRoute The association MPLSASInRoute provides a way to associate AS hops with MPLSRoutes. AS hops are instances of AutonomousSystem (from the CIM model [10]) and represent autonomous systems. The association definition is as follows: NAME MPLSASInRoute DESCRIPTION Associates AS hops with MPLSRoutes ABSTRACT false PROPERTIES mpRoute [ref MPLSRoute[0..n]] mpHop[ref AutonomousSystem[0..n]] mpIsStrict mpOrder =20 4.15.1 The reference mpRoute =20 This property contains an object reference to an MPLSRoute with which a number of autonomous system hops can be associated. The [0..n] cardinality indicates that there may be 0, 1, or more than Chadha Expires January 2001 36 =0C Policy Information Model for MPLS Traffic Engineering July 2000 one MPLSRoutes associated with any given AS hop, indicating that this AS hop is contained in all these routes. 4.15.2 The reference mpHop =20 This property contains an object reference to an AutonomousSystem that is a hop for an MPLSRoute. The [0..n] cardinality indicates that there may be 0, 1, or more than one AS hops associated with any given MPLSRoute. These are all the AS hops that are included in the route specification. 4.15.3 The property mpIsStrict Denotes whether the referenced AS hop is routed in a strict or loose fashion. The property definition is as follows: NAME mpIsStrict DESCRIPTION Denotes whether the referenced AS hop is Routed in a strict or loose fashion. SYNTAX boolean =20 4.15.4 The property mpOrder This property indicates the AS hop sequence, 1..n. The property definition is as follows: NAME mpOrder DESCRIPTION AS hop sequence SYNTAX uint16 4.16 The association MPLSSystemResources The association MPLSSystemResources associates a set of resources (object class MPLSResources) with an LSR (modeled by an instance of ComputerSystem as defined in the CIM model [13]). The association definition is as follows: NAME MPLSSystemResources DESCRIPTION Associates MPLS resources with an LSR. ABSTRACT false PROPERTIES mpResources[ref MPLSResources [0..1]] mpLSR [ref ComputerSystem[0..n]] 4.16.1 The reference mpResources Chadha Expires January 2001 37 =0C Policy Information Model for MPLS Traffic Engineering July 2000 =20 This property contains an object reference to an MPLSResources instance to which zero or one ComputerSystems (representing LSRs) can be associated. The [0..1] cardinality indicates that there may be zero or one instances of MPLSResources associated with any given LSR. 4.16.2 The reference mpLSR =20 This property contains an object reference to a ComputerSystem (representing an LSR) that is associated with MPLSResources. The [0..n] cardinality indicates that there may be 0, 1, or more than one LSRs associated with any given MPLSResources instance. These LSRs all have the same resource specifications. 4.17 The association MPLSEndpointResources The association MPLSEndpointResources associates a set of resources (object class MPLSResources) with an interface of an LSR (modeled by an instance of ProtocolEndpoint as defined in the CIM model [10]). The association definition is as follows: NAME MPLSEndpointResources DESCRIPTION Associates MPLS resources with an interface of an LSR. ABSTRACT false PROPERTIES mpResources[ref MPLSResources [0..1]] mpPE [ref ProtocolEndpoint [0..n]] 4.17.1 The reference mpResources =20 This property contains an object reference to an MPLSResources instance to which zero or one ProtocolEndpoints (representing interfaces on LSRs) can be associated. The [0..1] cardinality indicates that there may be zero or one instances of MPLSResources associated with any given LSR interface. 4.17.2 The reference mpPE =20 This property contains an object reference to a ProtocolEndpoint (representing an LSR interface) that is associated with MPLSResources. The [0..n] cardinality indicates that there may be 0, 1, or more than one LSR interfaces associated with any given MPLSResources instance. These LSR interfaces all have the same resource specifications. 4.18 The association MPLSActiveConnection Chadha Expires January 2001 38 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The association MPLSActiveConnection associates a ProtocolEndpoint with another and represents a link between them. Here ProtocolEndpoint (taken from the CIM model [10]) represents an LSR interface. The association definition is as follows: NAME MPLSActiveConnection DESCRIPTION Represents a link between two LSR interfaces ABSTRACT false DERIVED FROM ActiveConnection (from CIM [10]) PROPERTIES mpEndpoint1 [ref ProtocolEndpoint [0..n]] mpEndpoint2 [ref ProtocolEndpoint [0..n]] mpBandwidth mpMaxAllocMultiplier mpResourceClass 4.18.1 The reference mpEndpoint1 =20 This property contains a reference to a ProtocolEndpoint instance (representing an LSR interface) to which zero or more ProtocolEndpoints (also representing LSR interfaces) can be associated, representing a connection between the ProtocolEndpoints. The [0..n] cardinality indicates that there may be zero or more instances of ProtocolEndpoint associated with any given ProtocolEndpoint. 4.18.2 The reference mpEndpoint2 =20 This property contains a reference to a ProtocolEndpoint instance (representing an LSR interface) to which zero or more ProtocolEndpoints (also representing LSR interfaces) can be associated, representing a connection between the ProtocolEndpoints. The [0..n] cardinality indicates that there may be zero or more instances of ProtocolEndpoint associated with any given ProtocolEndpoint. 4.18.3 The property mpBandwidth Bandwidth for the link represented by this connection. The property definition is as follows: NAME mpBandwidth DESCRIPTION Link bandwidth SYNTAX uint16 4.18.4 The property mpMaxAllocMultiplier Chadha Expires January 2001 39 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The maximum allocation multiplier (MAM) (see [3]) of a resource determines the proportion of the resource that is available for allocation to traffic trunks. This attribute is applicable to link bandwidth. The values of the MAM can be chosen so that a resource can be under-allocated or over-allocated. A resource is said to be under-allocated if the aggregate demands of all traffic trunks that can be allocated to it are always less than the capacity of the resource. A resource is said to be over-allocated if the aggregate demands of all traffic trunks allocated to it can exceed the capacity of the resource. The property definition is as follows: NAME mpMaxAllocMultiplier DESCRIPTION Proportion of link bandwidth that is available for allocation. SYNTAX uint16 4.18.5 The property mpResourceClass This property describes the "class" that a resource belongs to. Thus a resource class can be viewed as a "color" assigned to a resource such that the set of resources with the same "color" conceptually belong to the same class. Resource classes can be used to implement a variety of policies. From a Traffic Engineering perspective, they can be used to implement many policies with regard to both traffic and resource oriented performance optimization. For example, resource class attributes can be used to apply uniform policies to a set of resources; specify the relative preference of sets of resources for path placement of traffic trunks; explicitly restrict the placement of traffic trunks to specific subsets of resources; etc. In general, a resource can be assigned more than one resource class attribute. For example, all of the OC-48 links in a given network may be assigned a distinguished resource class attribute. The subsets of OC-48 links which exist within a given domain of the network may be assigned additional resource class attributes in order to implement specific containment policies, or to architect the network in a certain manner. The property definition is as follows: NAME mpResourceClass DESCRIPTION Resource class assigned to this link. SYNTAX uint16[] 4.19 The association MPLSReverseDirTT The association MPLSReverseDirTT associates an MPLS traffic trunk with a traffic trunk going in the reverse direction. Chadha Expires January 2001 40 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The association definition is as follows: NAME MPLSReverseDirTT DESCRIPTION Associates a traffic trunk with another going in the reverse direction. ABSTRACT false PROPERTIES mpTT1 [ref MPLSTrafficTrunk [0..1]] mpTT2 [ref MPLSTrafficTrunk [0..1]] 4.19.1 The reference mpTT1 =20 This property contains an object reference to an MPLSTrafficTrunk instance to which zero or one MPLSTrafficTrunks can be associated. An MPLSReverseDirTT association between two traffic trunks represents the fact that these traffic trunks carry traffic in opposite directions. The [0..1] cardinality indicates that there may be zero or one instances of MPLSTrafficTrunk associated with any given MPLSTrafficTrunk. 4.19.2 The reference mpTT2 =20 This property contains an object reference to an MPLSTrafficTrunk instance to which zero or one MPLSTrafficTrunks can be associated. An MPLSReverseDirTT association between two traffic trunks represents the fact that these traffic trunks carry traffic in opposite directions. The [0..1] cardinality indicates that there may be zero or one instances of MPLSTrafficTrunk associated with any given MPLSTrafficTrunk. 4.20 The association MPLSEligibleRouteSpec The association MPLSEligibleRouteSpec associates a MPLS traffic trunk with a route specification that is a potential route for this traffic trunk. The association definition is as follows: NAME MPLSEligibleRouteSpec DESCRIPTION Associates a traffic trunk with a route specification that is a potential route for this traffic trunk. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpRoute [ref MPLSRouteSpec [0..n]] mpPreference mpIsMandatory 4.20.1 The reference mpTT =20 Chadha Expires January 2001 41 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This property contains an object reference to an MPLSTrafficTrunk instance associated with an MPLSRouteSpec. The [0..n] cardinality indicates that there may be zero or more instances of MPLSTrafficTrunk associated with any given MPLSRouteSpec; i.e. zero or more traffic trunks may share the same route specification, indicating that this route specification is an eligible route for these traffic trunks. 4.20.2 The reference mpRoute =20 This property contains an object reference to an MPLSRouteSpec that is associated with an MPLSTrafficTrunk. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRouteSpecs associated with any given MPLSTrafficTrunk instance; i.e. any traffic trunk can have multiple eligible route specifications. 4.20.3 The property mpPreference This property represents the preference for the referenced route by the referenced traffic trunk. The property definition is as follows: NAME mpPreference DESCRIPTION Preference for the referenced route for the referenced traffic trunk. SYNTAX uint16 4.20.4 The property mpIsMandatory Indicates whether this is a mandatory route for this traffic trunk or not. The property definition is as follows: NAME mpIsMandatory DESCRIPTION Indicates whether this is a mandatory route for this traffic trunk or not. SYNTAX boolean 4.21 The association MPLSCurrentlyAssignedLSP The association MPLSCurrentlyAssignedLSP associates the LSP to which a traffic trunk is assigned with that traffic trunk. The association definition is as follows: NAME MPLSCurrentlyAssignedLSP DESCRIPTION Associates a traffic trunk with the LSP Chadha Expires January 2001 42 =0C Policy Information Model for MPLS Traffic Engineering July 2000 assigned to it. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpLSP [ref MPLSLSP [0..n]] 4.21.1 The reference mpTT =20 This property contains an object reference to an MPLSTrafficTrunk instance to which zero or more MPLSLSPs can be associated. An MPLSCurrentlyAssignedLSP association between a traffic trunk and an LSP represents the fact that this LSP is currently carrying the traffic for this traffic trunk. The [0..n] cardinality indicates that there may be zero or more instances of MPLSTrafficTrunk associated with any given MPLSLSP, i.e. an LSP could be carrying traffic for zero or more traffic trunks. 4.21.2 The reference mpLSP =20 This property contains an object reference to an MPLSLSP instance to which zero or more MPLSTrafficTrunks can be associated. An MPLSCurrentlyAssignedLSP association between a traffic trunk and an LSP represents the fact that this LSP is currently carrying the traffic for this traffic trunk. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with any given MPLSTrafficTrunk, i.e. these LSPs are sharing the traffic load for this traffic trunk. 4.22 The association MPLSBackupLSP The association MPLSBackupLSP associates a backup LSP with an MPLS traffic trunk. The idea is that this LSP can be used as a backup for this traffic trunk if necessary. The association definition is as follows: NAME MPLSBackupLSP DESCRIPTION Associates a backup LSP with a traffic trunk. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpLSP [ref MPLSLSP [0..n]] mpPreference 4.22.1 The reference mpTT =20 This property contains an object reference to an MPLSTrafficTrunk instance with which zero or more MPLSLSPs can be associated. An MPLSBackupLSP association between a traffic trunk and an LSP represents the fact that this LSP is a backup for this traffic trunk and can be used in failure/congestion situations. The [0..n] Chadha Expires January 2001 43 =0C Policy Information Model for MPLS Traffic Engineering July 2000 cardinality indicates that there may be zero or more instances of MPLSTrafficTrunk associated with any given MPLSLSP, i.e. an LSP can be a backup for zero or more traffic trunks. 4.22.2 The reference mpLSP =20 This property contains an object reference to an MPLSLSP instance with which zero or more MPLSTrafficTrunks can be associated. An MPLSBackupLSP association between a traffic trunk and an LSP represents the fact that that this LSP is a backup for this traffic trunk and can be used in failure/congestion situations. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with any given MPLSTrafficTrunk, i.e. there may be zero or more backup LSPs for this traffic trunk. 4.22.3 The property mpPreference This property represents the preference for the referenced backup LSP by the referenced traffic trunk. In other words, an explicit order can be imposed on all the backup LSPs for a traffic trunk to indicate a sequence of backup LSPs ordered from most preferred to least preferred. The property definition is as follows: NAME mpPreference DESCRIPTION Preference for the referenced backup LSP for the referenced traffic trunk. SYNTAX uint16 4.23 The association MPLSRouteResourceProfile The association MPLSRouteResourceProfile associates a resource profile with an MPLS route. The association definition is as follows: NAME MPLSRouteResourceProfile DESCRIPTION Associates a resource profile with an MPLS route. ABSTRACT false PROPERTIES mpResourceProf[ref MPLSResourceProfile [0..1]] mpRoute[ref MPLSRoute [0..n]] 4.23.1 The reference mpResourceProf =20 This property contains an object reference to an MPLSResourceProfile instance associated with an MPLSRoute. The [0..1] cardinality Chadha Expires January 2001 44 =0C Policy Information Model for MPLS Traffic Engineering July 2000 indicates that there may be zero or one instances of MPLSResourceProfile associated with any given MPLSRoute. 4.23.2 The reference mpRoute =20 This property contains an object reference to an MPLSRoute that is associated with an MPLSResourceProfile. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRoutes associated with any given MPLSResourceProfile instance; i.e. zero or more MPLSRoutes can share the same resource profile definition. 4.24 The association MPLSRealizes The association MPLSRealizes associates an LSP with an MPLS route specification (MPLSRouteSpec). Such an association exists if the referenced LSP is an implementation of the referenced route specification. Recall that a route specification could be loosely or strictly specified; an LSP associated to a route specification via the MPLSRealizes association satisfies all the constraints laid down in this route specification. The association definition is as follows: NAME MPLSRealizes DESCRIPTION Associates an LSP with a route specification. ABSTRACT false PROPERTIES mpLSP [ref MPLSLSP [0..n]] mpRouteSpec [ref MPLSRouteSpec [0..n]] 4.24.1 The reference mpLSP =20 This property contains an object reference to an MPLSLSP instance associated with an MPLSRouteSpec. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with any given MPLSRouteSpec; i.e. zero or more LSPs can be a realization of the same route specification. 4.24.2 The reference mpRouteSpec =20 This property contains an object reference to an MPLSRouteSpec that is associated with an MPLSLSP. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRouteSpecs associated with any given MPLSLSP instance; i.e. any LSP can be a realization of have zero or more route specifications. 4.25 The association MPLSLSPinLSP Chadha Expires January 2001 45 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The association MPLSLSPinLSP associates an LSP with another LSP and indicates a hierachical relationship between the two LSPs. The association definition is as follows: NAME MPLSLSPinLSP DESCRIPTION Associates an LSP with another LSP, indicating a hierarchical relationship between the two. ABSTRACT false PROPERTIES mpContainingLSP [ref MPLSLSP [0..n]] mpContainedLSP [ref MPLSLSP [0..n]] 4.25.1 The reference mpContainingLSP =20 This property contains an object reference to an MPLSLSP instance associated with another MPLSLSP. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with other MPLSLSPs via this association, indicating that these LSPs all contain the referenced LSP. 4.25.2 The reference mpContainedLSP =20 This property contains an object reference to an MPLSLSP instance associated with another MPLSLSP. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with other MPLSLSPs via this association, indicating that these LSPs are all contained in the referenced LSP. 4.26 The association MPLSTrafficProfile The association MPLSTrafficProfile associates a traffic trunk with a traffic profile, represented by an instance of qosPolicyPRTrfcProf (defined in [6]). This traffic profile describes the characteristics of the traffic carried by the referenced traffic trunk. The association definition is as follows: NAME MPLSTrafficProfile DESCRIPTION Associates a traffic trunk with a traffic profile. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpTrfcProf[ref qosPolicyPRTrfcProf [0..1]] 4.26.1 The reference mpTT =20 This property contains an object reference to an MPLSTrafficTrunk instance associated with a qosPolicyPRTrfcProf. The [0..n] cardinality indicates that there may be zero or more instances of Chadha Expires January 2001 46 =0C Policy Information Model for MPLS Traffic Engineering July 2000 MPLSTrafficTrunk associated with any given qosPolicyPRTrfcProf; i.e. zero or more traffic trunks can share the same traffic profile specification. 4.26.2 The reference mpTrfcProf =20 This property contains an object reference to a qosPolicyPRTrfcProf that is associated with an MPLSTrafficTrunk. The [0..1] cardinality indicates that there may be zero or one traffic profiles associated with any given traffic trunk. 5. Usage Examples 5.1 Implementing Olympic Services In the following example, the following scenario is depicted: - Manual LSP creation - Manual traffic trunk creation - Manual assignment of LSPs to traffic trunks. This should be contrasted with the example in the next section (Section 5.2), where a traffic trunk is defined in a policy and LSPs are assumed to be created automatically by a traffic engineering system based on traffic trunk route specifications and network status. This example illustrates the use of the information model described in this document for representing policies that govern the assignment of different classes of traffic to different MPLS LSPs. Suppose that an enterprise needs to implement three classes of service, gold, silver, and bronze, between a pair of sites. In this scenario, we assume that traffic is marked using IP precedence (ToS) bits in the IP header as follows: Traffic entitled to gold service is marked with ToS=3D3 Traffic entitled to silver service is marked with ToS=3D2 Traffic entitled to bronze service is marked with ToS=3D1. Let the two sites be IP subnets 10.1.0.0/16 and 10.2.0.0/16, respectively. 5.1.1 MPLS LSP creation The first task is to set up the MPLS LSPs for traffic between these two sites (note that this step could be performed after the step in Section 5.1.2 as well). We will assume that three MPLS LSPs are to be created, each with different bandwidth constraints and different routing, to carry the three different types of service above: Chadha Expires January 2001 47 =0C Policy Information Model for MPLS Traffic Engineering July 2000 MPLS LSP 1: Carries gold service traffic MPLS LSP 2: Carries silver service traffic MPLS LSP 3: Carries bronze service traffic. To represent the creation of these three LSPs, we define one policy rule with three actions: - Each action corresponds to the creation of one LSP and is an instance of MPLSCreateLSPAction. - Each action refers to a route specification (instance of MPLSRouteSpec). - Each route specification is associated with a resource profile (instance of MPLSResourceProfile, association MPLSRouteResourceProfile) - Each route specification is associated with route hops for this route (a hop is an instance of ProtocolEndpoint) via association MPLSHopInRoute. Thus before defining the three policy actions, we need to define the corresponding three route specifications and the associated objects/associations. 5.1.1.1 Creation of route specifications We depict below the objects and associations that are created to represent the route specification for the Gold traffic class. Silver and bronze route specifications and the associated objects and associations are created in a similar manner. The following figure shows the object instances that are created to specify a route specification GoldRouteSpec with resource profile GoldResourceProfile and three hops, GoldHop1, GoldHop2, and GoldHop3. One instance of association MPLSRouteResourceProfile (which associates GoldRouteSpec and GoldResourceProfile) and three instances of association MPLSHopInRoute (which associate GoldRouteSpec with each of GoldHop1, GoldHop2, and GoldHop3) are created. Chadha Expires January 2001 48 =0C Policy Information Model for MPLS Traffic Engineering July 2000 +-----------------------+ | GoldResourceProfile | | (instance of | | MPLSResourceProfile) | +-----------^-----------+ GoldRouteResourceProfile | (instance of | MPLSRouteResourceProfile) | | +-----------v---------v--------+ | GoldRouteSpec (instance of | | MPLSRouteSpec) | +-^-----------------^--------^-+ | | | GoldHop1InRoute | GoldHop2InRoute| | GoldHop3InRoute (instance of | (instance of | | (instance of MPLSHopInRoute) | MPLSHopInRoute)| | MPLSHopInRoute) | | | | | | | | | +---------------v-+ +-----------v-----+ +v----------------+ | GoldHop1 | | GoldHop2 | | GoldHop3 | | (instance of | | (instance of | | (instance of | |ProtocolEndpoint)| |ProtocolEndpoint)| |ProtocolEndpoint)| +-----------------+ +-----------------+ +-----------------+ Figure 5. Gold route specification with resource profile and three hops 5.1.1.2 Creation of LSPs Once route specifications for the gold, silver, and bronze traffic have been created, the actions to create LSPs corresponding to these three route specifications can be instantiated. Assume that the previous step created three route specifications named GoldRouteSpec (see Figure 5 above), SilverRouteSpec, and BronzeRouteSpec, with the obvious semantics. Three actions are then created: Action 1: (instance of MPLSCreateLSPAction) Name: CreateGoldLSP mpCreateLSP: Action 2: (instance of MPLSCreateLSPAction) Name: CreateSilverLSP mpCreateLSP: Action 3: (instance of MPLSCreateLSPAction) Name: CreateBronzeLSP mpCreateLSP: These three actions each reference an instance of an MPLSRouteSpec object, whose creation was discussed above. Chadha Expires January 2001 49 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The result of implementing the policy rule containing these three actions (note that this policy rule would contain no conditions, only Actions 1, 2, 3 described earlier) is to create three instances of MPLSLSP, namely GoldLSP, SilverLSP, and BronzeLSP (say). Each created instance of MPLSLSP will be associated with the hops in its path and with the appropriate resource profile. Note that the hops in each LSP's path could contain new hops that were not specified in the corresponding route specification, if the latter was an incomplete specification of the route to be followed by the LSP. Each instance of MPLSLSP will also be associated with the instance of MPLSRouteSpec that it implements, via the MPLSRealizes association. The figure below shows the MPLSLSP GoldLSP created from the route specification GoldRouteSpec. Here we assume that the LSP has four hops, which include the three hops specified as belonging to the route specification GoldRouteSpec and one additional new hop, GoldHop4. Instances SilverLSP and BronzeLSP have similar associations. Chadha Expires January 2001 50 =0C Policy Information Model for MPLS Traffic Engineering July 2000 +-----------------------+ ------------------> GoldResourceProfile | | | (instance of | | | MPLSResourceProfile) | | +-----------^-----------+ | GoldRouteResourceProfile | | (instance of | | MPLSRouteResourceProfile) | | | | +-----------v---------v--------+ | | GoldRouteSpec (instance of <--------------- | | MPLSRouteSpec | | | +^---------------^---------^---+ | | | | | | | GoldHop1InRoute|GoldHop2InRoute| | GoldHop3InRoute | | (instance of | (instance of | | (instance of | | MPLSHopInRoute)|MPLSHopInRoute)| | MPLSHopInRoute) | | | | | | | | | | | | | | | | | +----------------v+ +-----------v-----+ +v----------------+ | | | GoldHop1 | | GoldHop2 | | GoldHop3 | | | | (instance of | | (instance of | | (instance of | | | |ProtocolEndpoint)| |ProtocolEndpoint)| |ProtocolEndpoint)| | | +-----------------+ +-----------------+ +-----------------+ | | | | | | | GoldHop1InLSP | GoldHop2InLSP | | GoldHop3InLSP | | (instance of | (instance of | | (instance of | | MPLSHopInRoute) | MPLSHopInRoute)| | MPLSHopInRoute)| | | | | | | | | | | | | | | | | +-v----------------v---------v-+ | ------------------> GoldLSP (instance of <--------------- GoldLSPProfile | MPLSLSP | GoldLSPSpec (instance of +--------------^---------------+ (instance of MPLSRouteResourceProfile) | MPLSRealizes) | | | GoldHop4InLSP | (instance of | MPLSHopInRoute) +-----------v--------+ | GoldHop4 | | (instance of | | ProtocolEndpoint) | +--------------------+ Figure 6. Gold LSP and its associations 5.1.2 Policies for traffic trunks Chadha Expires January 2001 51 =0C Policy Information Model for MPLS Traffic Engineering July 2000 Once LSPs have been created for each class of service, the next requirement is to create policies that activate traffic trunks that will be transported on these LSPs (this step could have been performed before the previous one too). The policy rules that are to be created for site 1 are: Policy Rule 1: If (source address is in IP subnet 10.1.0.0/16) and (destination address is in IP subnet 10.2.0.0/16) and (ToS=3D3) then (traffic is assigned to GoldTrunk) Policy Rule 2: If (source address is in IP subnet 10.1.0.0/16) and (destination address is in IP subnet 10.2.0.0/16) and (ToS=3D2) then (traffic is assigned to SilverTrunk) Policy Rule 3: If (source address is in IP subnet 10.1.0.0/16) and (destination address is in IP subnet 10.2.0.0/16) and (ToS=3D1) then (traffic is assigned to BronzeTrunk) The conditions in each of the above three rules can be represented using conditions with variables and values, as described in the Policy Framework QoS Information Model (see [6]). The actions are described using instances of the MPLSActivateTTAction object class, as described in Section 5.1.2.2. To represent the creation of these three traffic trunks, we define three policy rules, each with three conditions and one action: - Each condition is defined to represent the conditions described above using the mechanisms discussed in QPIM [6]. - Each action corresponds to the activation of one traffic trunk and is an instance of MPLSActivateTTAction. - Each action refers to a traffic trunk (instance of MPLSTrafficTrunk). - Each traffic trunk is associated with a traffic profile (instance of qosPolicyPRTrfcProf, association MPLSTrafficProfile). Thus before defining the three policy rules, we need to define the corresponding three traffic trunks and the associated traffic profiles and associations that will be referenced by the three actions of these rules. 5.1.2.1 Creation of traffic trunks We depict below the objects and associations that are created to represent the traffic trunk for the Gold traffic class. Silver and Chadha Expires January 2001 52 =0C Policy Information Model for MPLS Traffic Engineering July 2000 bronze traffic trunks and the associated objects and associations are created in a similar manner. The following figure shows the object instances that are created to specify a traffic trunk GoldTrunk with traffic profile GoldTrafficProfile. An instance of association MPLSTrafficProfile (which associates GoldTrunk and GoldTrafficProfile) is created. +-----------------------+ | GoldTrunk | | (instance of | | MPLSTrafficTrunk) | +-----------^-----------+ GoldTrunkTrafficProfile | (instance of | MPLSTrafficProfile)| | +-----------v---------v-------------+ | GoldTrafficProfile (instance of | | qosPolicyPRTrfcProf | +-^-----------------^--------^------+ Figure 7. Gold traffic trunk and its traffic profile 5.1.2.2 Activation of traffic trunks Once traffic trunks for the gold, silver, and bronze traffic have been defined, the actions to activate these three traffic trunks can be defined. Assume that the previous step created three traffic trunks named GoldTrunk (see Figure 7 above), SilverTrunk, and BronzeTrunk, with the obvious semantics. Three actions are then created: Action 4: (instance of MPLSActivateTTAction) Name: CreateGoldTrunk mpTrafficTrunk: Action 5: (instance of MPLSActivateTTAction) Name: CreateSilverTrunk mpTrafficTrunk: Action 6: (instance of MPLSActivateTTAction) Name: CreateBronzeLSP mpTrafficTrunk: These three actions each reference an instance of an MPLSTrafficTrunk object, whose creation was discussed above and depicted in Figure 7 (for the GoldTrunk object). The three policy rules described at the beginning of Section 5.1.2 each contain one of the above actions (i.e. Policy Rule 1 contains Action 4, Policy Rule 2 contains Action 5, and Policy Rule 3 Chadha Expires January 2001 53 =0C Policy Information Model for MPLS Traffic Engineering July 2000 contains Action 6). Policy Rules 1, 2, and 3 also contain the conditions described earlier. The result of implementing these three policy rules is to activate the three traffic trunks described above. 5.1.3 Assignment of LSPs to traffic trunks The next requirement is to create policies that assign LSPs to the previously activated traffic trunks. The policy rules that are to be created for site 1 are: Policy Rule 4: Send traffic for GoldTrunk over GoldLSP Policy Rule 5: Send traffic for SilverTrunk over SilverLSP Policy Rule 6: Send traffic for BronzeTrunk over BronzeLSP Note that the above policy rules contain no conditions, only actions. The actions are described using instances of the MPLSAssignLSPAction object class. Action 7: Name: AssignGoldLSP mpTrafficTrunk: mpAssignedLSP: GoldLSP Action 8: Name: AssignSilverLSP mpTrafficTrunk: mpAssignedLSP: SilverLSP Action 9: Name: AssignBronzeLSP mpTrafficTrunk: mpAssignedLSP: BronzeLSP The effect of executing these rules is to assign the appropriate LSPs to the desired traffic trunks. 5.2 Creating traffic trunks In this example, we demonstrate the use of policies for activating traffic trunks and related information. A policy is defined that describes the traffic that will belong to this traffic trunk. Associated with the traffic trunk is a traffic profile that describes the resource requirements for this trunk. Also associated with the traffic trunk are one or more route specifications that Chadha Expires January 2001 54 =0C Policy Information Model for MPLS Traffic Engineering July 2000 specify possible ways of routing this traffic trunk through the network. Each such route specification has its hops and its resource requirements specified. The idea is that a traffic engineering module will use these specifications, along with information about the current nodes and links in the network, to perform computations that will yield a decision about which of the above specified route specifications should be used to create LSPs. In other words, not all route specifications will necessarily be used to create LSPs. The number of LSPs actually created to carry a traffic trunk will depend on the network resiliency requirements. Thus backup LSPs could be created in situations where high survivability and high performance is required, whereas backup LSPs may not be created for best-effort traffic. However, in cases of congestion/failures, existing route specifications can be used to create new LSPs to alleviate/remedy the problem. Route specification attributes are used to indicate routing preferences to aid the traffic engineering module in deciding which route specifications should be used to create LSPs. Note that another scenario could be that no route specifications are provided by the policy and the traffic engineering module computes suitable LSPs based on traffic trunk attributes alone. Initially, we assume that the following information is known to the management system: - All the LSRs in the network (instances of ComputerSystem (defined in CIM model [10])) - All the MPLS interfaces on these LSRs (instances of ProtocolEndpoint (defined in CIM model [10])) - All the links between MPLS interfaces on LSRs (instances of MPLSActiveConnection). The network administrator then defines policies for traffic trunks. For example, the following is an example of such a policy: If source address =3D 192.8.0.0/16 AND destination address =3D 128.5.0.0/16 AND ToS=3D3 then Assign this traffic to Traffic Trunk TT1 AND Police TT1 according to its traffic profile and drop all out-of-profile packets. All relevant attributes of TT1 must be specified. Related information such as a traffic profile TP1 for this traffic trunk must also be specified, including all relevant attributes of TP1, so that TP1 can be used for policing the traffic trunk. This is achieved by instantiating an instance of MPLSTrafficTrunk (named TT1), an instance of qosPolicyPRTrfcProf (named TP1), and an instance of association MPLSTrafficProfile relating TT1 to TP1. Further, TT1 could have a number of MPLSRouteSpec instances associated with it using the MPLSEligibleRouteSpec association. Chadha Expires January 2001 55 =0C Policy Information Model for MPLS Traffic Engineering July 2000 These route specifications basically describe possible paths for routing the trunk TT1 through the network. The route specifications can have associations to ProtocolEndpoint instances (association MPLSHopInRoute) that represent LSR interfaces that are hops for the route; the route specifications could also have associations to AutonomousSystem instances (association MPLSASInRoute) that are hops for the route. Thus each route can be loosely or strictly specified. Each MPLSRouteSpec has an MPLSResourceProfile instance associated with it via the MPLSRouteResourceProfile association. The MPLSResourceProfile instance contains information about the resources for this route specification, i.e. the average and maximum traffic rates and burst sizes. The above policy rule is represented using instances of PolicyRule (from [5]), qosPolicySimpleCondition (to represent the "if" portion of the rule), MPLSActivateTTAction (to represent the action of activating this traffic trunk), and qosPolicyPRAction (to represent the policing actions described above. The latter object class (qosPolicyPRAction ) allows the network operator to specify the action to take for non-conforming traffic (e.g. shape, drop, or re- mark). In this case, the action to be taken is to drop all non- conforming traffic. For details about the usage of qosPolicyPRAction, see QPIM [6]. The rule is structured as follows: - PolicyRule represents the policy rule described above and contains three conditions (three instances of qosPolicySimpleCondition) and two actions (instances of MPLSActivateTTAction and qosPolicyPRAction). - The instances of qosPolicySimpleCondition represent the classifier described above, i.e. source address =3D 192.8.0.0/16 AND destination address =3D 128.5.0.0/16 AND ToS=3D3. These conditions are represented using instances of qosPolicyVariable, qosPolicyIPv4AddrValue, and qosPolicyIntegerValue. - The instance of MPLSActivateTTAction contains a reference to TT1, which is associated with TP1 using association MPLSTrafficProfile, as described above. - The instance of qosPolicyPRAction (see [6] for details) contains a reference to TP1 and specifies that non-conforming traffic should be dropped (property qpOutOfProfileAction is set to 1 for DISCARD) - TT1 is associated with one or more MPLSRouteSpecs via the MPLSEligibleRouteSpec association. - Each instance of MPLSRouteSpec may be associated with an instance of MPLSResourceProfile (via the MPLSRouteResourceProfile association) and with hops that could be ProtocolEndpoints or AutonomousSystems (via the MPLSHopInRoute and the MPLSASInRoute associations, respectively). The above rule is processed by the traffic engineering module as described at the beginning of this section. Chadha Expires January 2001 56 =0C Policy Information Model for MPLS Traffic Engineering July 2000 5.3 Load balancing In order to perform load balancing, a traffic stream between two nodes must be assigned to two or more LSPs at the ingress node. Policies can be designed to decide how traffic gets partitioned across LSPs. Assume that a traffic stream is to be load-balanced across two existing LSPs. Possible approaches include: - Define two parallel traffic trunks between the two nodes and assign a different LSP to each traffic trunk. The proportion of the traffic stream to be carried by each traffic trunk is specified by the mpTrafficProportion property of the MPLSTrafficTrunk object class. Thus one could specify that 80% of the traffic is to be carried across the first LSP and 20% across the second. This is the approach referred to in Section 5.6.5 of RFC 2702. - Define one traffic trunk and assign the two LSPs to carry its traffic. This will result in the traffic being shared equally by the two LSPs. From the information modeling perspective, the first option can be implemented by activating two instances of MPLSTrafficTrunk with the value of the property mpTrafficProportion set to 80 for the first trunk and to 20 for the second (using policy action MPLSActivateTTAction as described earlier); and subsequently assigning an LSP to each of these traffic trunks using the MPLSAssignLSPAction as described in the previous example. The second option can be implemented by creating one instance of MPLSTrafficTrunk (using policy action MPLSActivateTTAction); and subsequently assigning two LSPs to this traffic trunk using two instances of the MPLSAssignLSPAction. 5.4 Implementing Service Level Agreements (SLAs) Suppose a service provider has an SLA with a customer that guarantees premium quality of service for that customer during business hours (8:00am to 5:00pm) and best-effort service during non-business hours. Let's say that the service provider wishes to implement this SLA by assigning the customer's traffic during business hours to a certain LSP L1 that carries premium traffic; and by assigning the customer's traffic during non-business hours to another LSP L2 that carries best-effort traffic. Policy rules that model this requirement can be specified as follows: Policy Rule 1: Define and activate traffic trunk for this customer's traffic. qosPolicySimpleConditions: Chadha Expires January 2001 57 =0C Policy Information Model for MPLS Traffic Engineering July 2000 MPLSActivateTTAction: Policy Rule 2: Assign premium LSP L1 for business hours Condition: The time is between 8:00am - 5:00pm Action: Assign LSP L1 to traffic trunk TT1 This policy is modeled as follows: an instance of PolicyTimePeriodCondition (defined in PCIM [5]) is used to model the above condition; and an instance of MPLSAssignLSPAction is used to model the above action. Policy Rule 3: Assign best-effort LSP L2 for non-business hours Condition: The time is between 5:00pm - 8:00am Action: Assign LSP L2 to traffic trunk TT1 This policy is modeled as follows: an instance of PolicyTimePeriodCondition (defined in PCIM [5]) is used to model the above condition; and an instance of MPLSAssignLSPAction is used to model the above action. 6. Security Considerations The security issues inherent in a policy-based management system are those of ensuring that only authorized users are allowed to manipulate policies, since these policies exert a large degree of control over the MPLS network. Such issues must be addressed by the implementation of the policy management system. 7. Conclusions This document provides a draft information model for policy-enabled MPLS network engineering. The authors of this draft would like to propose incorporation of this material into working group drafts in the mpls and/or policy working groups. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Chadha Expires January 2001 58 =0C Policy Information Model for MPLS Traffic Engineering July 2000 3 Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J., "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. 4 Li, T. and Y. Rekhter, "Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998. 5 Moore, B., Ellesson, E. , Strassner, J., "Policy Core Information Model -- Version 1 Specification", Internet Draft draft-ietf- policy-core-info-model-06.txt, May 2000. 6 Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., "Policy Framework QoS Information Model", Internet Draft draft-ietf- policy-qos-info-model-01.txt. 7 Mahon, H., Bernet, Y., Herzog, S., "Requirements for a Policy Management System", Internet Draft draft-ietf-policy-req-01.txt, October 1999. 8 Srinivasan, C., Viswanathan, A., Nadeau, T.D., "MPLS Traffic Engineering Management Information Base Using SMIv2", Internet Draft draft-ietf-mpls-te-mib-03.txt, March 2000. 9 Srinivasan, C., Viswanathan, A., Nadeau, T.D., "MPLS Label Switch Router Management Information Base Using SMIv2", Internet Draft draft-ietf-mpls-lsr-mib-04.txt, April 2000. 10 Distributed Management Task Force, Inc., "Common Information Model (CIM) Schema, version 2.3, March 2000. The components of the CIM v2.3 schema are available via links on the following DMTF web page: http://www.dmtf.org/spec/cims.html 11 Awduche, D.O., Berger, L., Gan, D., Li, T., Srinivasan, V., Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", Internet Draft draft-mpls-rsvp-lsp-tunnel-06.txt, July 2000. 12 Jamoussi, B., Aboul-Magd, O., Andersson, L., Ashwood-Smith, P., Hellstrand, F., Sundell, K., Callon, R., Dantu, R., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Halpern, J., Heinanen, J., Kilty, T., Malis, A., Vaananen, P., Wu, L., "Constraint-Based LSP Setup using LDP", Internet Draft draft-ietf-mpls-cr-ldp-04.txt, July 2000. 13 Wright, S., Herzog, S., Reichmeyer, F., Jaeger, R., "Requirements for Policy Enabled MPLS", Internet Draft draft-wright-policy- mpls-00.txt, March 2000. 14 Wright, S., Reichmeyer, F., Jaeger, R., Gibson, M., "Policy-Based Load-Balancing in Traffic-Engineered MPLS Networks", Internet Draft draft-wright-mpls-te-policy-00.txt, June 2000. Chadha Expires January 2001 59 =0C Policy Information Model for MPLS Traffic Engineering July 2000 9. Acknowledgments Many thanks are due to Tony Bogovic, Ravi Vaidyanathan, and George Mykoniatis for their insights and careful reviews of this material. 10. Author's Addresses Ritu Chadha Telcordia Technologies 445 South Street Morristown NJ 07960 Phone: +1-973-829-4869 Email: chadha@research.telcordia.com Huai-An (Paul) Lin Telcordia Technologies 445 South Street Morristown NJ 07960 Phone: +1-973-829-2412 Email: hlin1@telcordia.com Chadha Expires January 2001 60 =0C Policy Information Model for MPLS Traffic Engineering July 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN 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. Chadha Expires January 2001 61 =0C --Flink_of_Cows_031_000-- From majordomo@raleigh.ibm.com Mon Jul 17 15:46:05 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06207 for ; Mon, 17 Jul 2000 15:46:02 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA25390; Mon, 17 Jul 2000 15:44:06 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA26596; Mon, 17 Jul 2000 15:44:07 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34740; Mon, 17 Jul 2000 15:20:39 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34728; Mon, 17 Jul 2000 15:20:36 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA29714 for ; Mon, 17 Jul 2000 15:20:35 -0400 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA25094 for ; Mon, 17 Jul 2000 15:20:32 -0400 Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6HJJgR28075; Mon, 17 Jul 2000 15:19:42 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id PAA00605; Mon, 17 Jul 2000 15:19:42 -0400 (EDT) Message-Id: <200007171919.PAA00605@monday.research.telcordia.com> Date: Mon, 17 Jul 2000 15:19:42 -0400 (EDT) From: Ritu Chadha Subject: Re: Policy Information Model for MPLS Traffic Engineering To: chadha@research.telcordia.com, policy@raleigh.ibm.com, mpls@UU.NET, tnadeau@cisco.com Cc: chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@mailee.research.telcordia.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: wM0b/lZmaE2caRc51tgWEQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ritu Chadha Tom, >Date: Mon, 17 Jul 2000 14:21:49 -0400 >To: Ritu Chadha , policy@raleigh.ibm.com, >mpls@UU.NET >From: "Thomas D. Nadeau" >Subject: Re: Policy Information Model for MPLS Traffic Engineering >Cc: chadha@research.telcordia.com > > Hi, > > A few questions about your draft. > > 1) How does this draft differ from say the use > of COPS and the definition of a PIB > instead of using the object model? The information model in our draft would be used to describe policies that a PDP would implement, in accordance with the policy framework. The PDP could implement the policies via COPS and appropriate PIBs. Appropriate PIBS could very well be defined based on some of the information presented in our model. > > 2) It is not clear to me whether or not it is your > intent to make this object model useful > for both MPLS network management or just > only for off-line TE. It seems from reading > your document that your intent is to do > both. > That's correct; the intent is to be able to do both. > > --Tom Ritu ============================================================================= Ritu Chadha Senior Scientist Telcordia Technologies (973) 829-4869 (voice) MCC 1J-218R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From majordomo@raleigh.ibm.com Mon Jul 17 19:42:08 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22228 for ; Mon, 17 Jul 2000 19:42:07 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA28990; Mon, 17 Jul 2000 18:06:22 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA30616; Mon, 17 Jul 2000 18:06:23 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36080; Mon, 17 Jul 2000 17:41:33 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31944; Mon, 17 Jul 2000 17:41:25 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA20546 for ; Mon, 17 Jul 2000 17:41:29 -0400 Received: from brmnj-fw ([63.89.157.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id RAA14632 for ; Mon, 17 Jul 2000 17:41:24 -0400 Received: by BMAILNJ with Internet Mail Service (5.5.2650.21) id <3VY46J1T>; Mon, 17 Jul 2000 17:33:50 -0400 Message-Id: <6399122981E1D211AB490090271E0AA38B1DEA@BMAILNJ> From: "Francis Reichmeyer (IPHighway MA)" To: "'Thomas D. Nadeau'" , Ritu Chadha , chadha@research.telcordia.com, policy@raleigh.ibm.com, mpls@UU.NET Cc: chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@mailee.research.telcordia.com Subject: RE: Policy Information Model for MPLS Traffic Engineering Date: Mon, 17 Jul 2000 17:33:43 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Francis Reichmeyer (IPHighway MA)" Hi, I haven't had the chance to read the draft being discussed here yet (still looking for a pointer to it, can anyone help with that? :^). That said, there is something similar going on with Diff Serv/QoS. The Policy Framework WG has specified a QoS Information Model while the RAP WG is working on a Diff Serv/QoS PIB. Along with the QoS Information Model, there is also a LDAP schema, but this is separate from the PIB (as it should be). So, there is some precedent for this "information architecture." Again, I haven't seen the MPLS TE Information Model draft to verify it's at the same (abstraction) level as the QoS Info Model, and there is no MPLS/TE PIB (yet ;^), so I can't say the same relationship applies, but it could. Thanks, -Fran > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, July 17, 2000 4:23 PM > To: Ritu Chadha; chadha@research.telcordia.com; > policy@raleigh.ibm.com; > mpls@UU.NET > Cc: chadha@research.telcordia.com; hlin1@telcordia.com; > mykoniat@mailee.research.telcordia.com > Subject: Re: Policy Information Model for MPLS Traffic Engineering > > > > Hi Ritu, > > My comments are inline: > > > > A few questions about your draft. > > > > > > 1) How does this draft differ from say the use > > > of COPS and the definition of a PIB > > > instead of using the object model? > > > >The information model in our draft would be used to describe policies > >that a PDP would implement, in accordance with the policy framework. > >The PDP could implement the policies via COPS and appropriate PIBs. > >Appropriate PIBS could very well be defined based on some of the > >information presented in our model. > > I disagree. This is what the PIB should be used for. > The object model you define could very well be done by > a proprietary vendor. I don't see the need or advantage > to do so in a standard way. What advantages do you see of > defining such an object model versus using say, a PIB > and COPS to define and implement policy for MPLS? > > > > 2) It is not clear to me whether or not it is your > > > intent to make this object model useful > > > for both MPLS network management or just > > > only for off-line TE. It seems from reading > > > your document that your intent is to do > > > both. > > > > > > >That's correct; the intent is to be able to do both. > > In terms of device management, is it then your > assertion that the MIBs will need to be re-aligned to fit > in with your object model in order to do device-level > management? As I see it, I don't see how the MIBs as they > are defined today, fit in with your object model. If anything, > I think that the object model should be changed to reflect > that which is defined in the MIBs. > > --Tom > > > From majordomo@raleigh.ibm.com Mon Jul 17 19:48:25 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24347 for ; Mon, 17 Jul 2000 19:48:25 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA28470; Mon, 17 Jul 2000 18:06:19 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA34154; Mon, 17 Jul 2000 18:06:19 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43980; Mon, 17 Jul 2000 17:44:51 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29636; Mon, 17 Jul 2000 17:44:48 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA32886 for ; Mon, 17 Jul 2000 17:44:52 -0400 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA24366 for ; Mon, 17 Jul 2000 17:44:49 -0400 Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6HLi8R06059; Mon, 17 Jul 2000 17:44:08 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id RAA00652; Mon, 17 Jul 2000 17:44:07 -0400 (EDT) Message-Id: <200007172144.RAA00652@monday.research.telcordia.com> Date: Mon, 17 Jul 2000 17:44:07 -0400 (EDT) From: Ritu Chadha Subject: Re: Policy Information Model for MPLS Traffic Engineering To: policy@raleigh.ibm.com, mpls@UU.NET, tnadeau@cisco.com Cc: chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: yRYjNFJLxZsT1Hlyz0nvXA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ritu Chadha Tom, Comments inline. > Hi Ritu, > > My comments are inline: > >> > A few questions about your draft. >> > >> > 1) How does this draft differ from say the use >> > of COPS and the definition of a PIB >> > instead of using the object model? >> >>The information model in our draft would be used to describe policies >>that a PDP would implement, in accordance with the policy framework. >>The PDP could implement the policies via COPS and appropriate PIBs. >>Appropriate PIBS could very well be defined based on some of the >>information presented in our model. > > I disagree. This is what the PIB should be used for. >The object model you define could very well be done by >a proprietary vendor. I don't see the need or advantage >to do so in a standard way. What advantages do you see of >defining such an object model versus using say, a PIB >and COPS to define and implement policy for MPLS? The definition of such policy information models is the whole raison d'etre of the Policy Framework WG. The following snippet from "Requirements for a Policy Management System", draft-ietf-policy-req-01.txt, summarizes the need for a standardized common information model: "...centralized management leads to the need for a repository; scalability requires a means to commu- nicate the data beyond the repository; abstraction requires a common information model; automation requires the abstraction and components to perform actions based on management data and real-time inputs. Please refer to the above draft for details. The charter of the policy WG states clearly that one must be able to translate high-level policy information into device configuration information. This will require coordination with MIB and PIB development work because, as you correctly point out, ultimately the devices will be configured using COPS/SNMP/etc. A related document ("Policy-Based Load-Balancing in Traffic-Engineered MPLS Networks", draft-wright-mpls-te-policy-00.txt) also aims to provide guidance for the development of a PIB for MPLS based on a policy information model. > >> > 2) It is not clear to me whether or not it is your >> > intent to make this object model useful >> > for both MPLS network management or just >> > only for off-line TE. It seems from reading >> > your document that your intent is to do >> > both. >> > >> >>That's correct; the intent is to be able to do both. > > In terms of device management, is it then your >assertion that the MIBs will need to be re-aligned to fit >in with your object model in order to do device-level >management? As I see it, I don't see how the MIBs as they >are defined today, fit in with your object model. If anything, >I think that the object model should be changed to reflect >that which is defined in the MIBs. No; there should be a way to map from the policy information model to the appropriate MIBs/PIBs, but I don't see a need to re-align the MIBs. I disagree with your statement that current MIBs do not fit in with our object model; we have based some of our LSP model on the MPLS TE MIB as noted in our draft. Since there are currently no MPLS TE PIBs defined, I can't comment on the required re-alignment there. If it turns out that there is a fundamental misalignment and that there is no way to map from our information model to existing MIBs, then we may need to revise our information model. We plan to do this as the relevant MIBs mature and PIBs are defined. > > --Tom > > Ritu From majordomo@raleigh.ibm.com Tue Jul 18 05:26:35 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20827 for ; Tue, 18 Jul 2000 05:26:34 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA20804; Tue, 18 Jul 2000 05:24:21 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA28376; Tue, 18 Jul 2000 05:22:56 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44516; Tue, 18 Jul 2000 04:16:06 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24712; Tue, 18 Jul 2000 04:15:55 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA31858 for ; Tue, 18 Jul 2000 04:14:53 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA34776 for ; Tue, 18 Jul 2000 04:13:47 -0400 Received: from ccrle.nec.de (santiago.berlin.ccrle.nec.de [192.168.100.61]) by tokyo.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id e6I8FLR02245; Tue, 18 Jul 2000 10:15:21 +0200 (CEST) Message-Id: <39741172.37D3B9C6@ccrle.nec.de> Date: Tue, 18 Jul 2000 10:12:34 +0200 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en,de Mime-Version: 1.0 To: "Thomas D. Nadeau" Cc: policy@raleigh.ibm.com, mpls@UU.NET Subject: Re: Policy Information Model for MPLS Traffic Engineering References: <4.3.2.7.2.20000717220513.04c86a70@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Tom, At least our draft (draft-isoyama-policy-mpls-info-model-00.txt) is intend to go into the policy working group. In a later stage, e.g., for the definition of a MPLS PIB, the situation may change. Marcus "Thomas D. Nadeau" wrote: > > Hi, > > >The definition of such policy information models is the > >whole raison d'etre of the Policy Framework WG. The following > >snippet from "Requirements for a Policy Management System", > >draft-ietf-policy-req-01.txt, > >summarizes the need for a standardized common information model: > > I thought that the purpose of the MPLS WG was to define > protocols (and MIBs to manage them) not policy, but I may be > mistaken here. ;) I can understand holding topological information > or such network-wide things, but the inclusion of other information > into this standard object model seems redundant, doesn't it? > Isn't this why we have the MIBs and PIBs? That is, to define > what is manageable, and how some of those managed objects are > provisioned via a defined policy? Why should we spend time > defining an object model which has basically already been > defined for MPLS? > > --Tom -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner New address starting 9/1/2000 Postal Mail: Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 905110 Fax: +49 (0)6221/ 9051155 Address valid until 8/31/2000 Postal Mail: Hardenbergplatz 2 D-10623 Berlin Germany Phone: +49 (0)30/ 25 42 30 17 Fax: +49 (0)30/ 25 42 30 99 From majordomo@raleigh.ibm.com Tue Jul 18 05:29:42 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21830 for ; Tue, 18 Jul 2000 05:29:41 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA30756; Tue, 18 Jul 2000 05:23:47 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA06370; Tue, 18 Jul 2000 05:22:54 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37890; Tue, 18 Jul 2000 04:10:08 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA45148; Tue, 18 Jul 2000 04:09:32 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA32340 for ; Tue, 18 Jul 2000 04:09:08 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA26862 for ; Tue, 18 Jul 2000 04:09:00 -0400 Received: from ccrle.nec.de (santiago.berlin.ccrle.nec.de [192.168.100.61]) by tokyo.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id e6I8BER02229; Tue, 18 Jul 2000 10:11:14 +0200 (CEST) Message-Id: <3974107B.46942CE9@ccrle.nec.de> Date: Tue, 18 Jul 2000 10:08:27 +0200 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en,de Mime-Version: 1.0 To: "Thomas D. Nadeau" Cc: policy@raleigh.ibm.com, mpls@UU.NET Subject: Re: Policy Information Model for MPLS Traffic Engineering References: <4.3.2.7.2.20000717161210.04c6f9b0@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Tom, A propriatary vendor can still define its own information model, whether it succeeds on the marcket is an other story. But that argument paly agains many many IETF standards. Marcus "Thomas D. Nadeau" wrote: > >The information model in our draft would be used to describe policies > >that a PDP would implement, in accordance with the policy framework. > >The PDP could implement the policies via COPS and appropriate PIBs. > >Appropriate PIBS could very well be defined based on some of the > >information presented in our model. > > I disagree. This is what the PIB should be used for. > The object model you define could very well be done by > a proprietary vendor. I don't see the need or advantage > to do so in a standard way. What advantages do you see of > defining such an object model versus using say, a PIB > and COPS to define and implement policy for MPLS? -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner New address starting 9/1/2000 Postal Mail: Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 905110 Fax: +49 (0)6221/ 9051155 Address valid until 8/31/2000 Postal Mail: Hardenbergplatz 2 D-10623 Berlin Germany Phone: +49 (0)30/ 25 42 30 17 Fax: +49 (0)30/ 25 42 30 99 From majordomo@raleigh.ibm.com Tue Jul 18 05:32:52 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22906 for ; Tue, 18 Jul 2000 05:32:51 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA30980; Tue, 18 Jul 2000 05:23:09 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id FAA32978; Tue, 18 Jul 2000 05:22:53 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47054; Tue, 18 Jul 2000 03:48:14 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47090; Tue, 18 Jul 2000 03:46:00 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id DAA36962 for ; Tue, 18 Jul 2000 03:45:23 -0400 Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id DAA34088 for ; Tue, 18 Jul 2000 03:45:14 -0400 Received: from ccrle.nec.de (santiago.berlin.ccrle.nec.de [192.168.100.61]) by tokyo.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id e6I7kxR02083; Tue, 18 Jul 2000 09:46:59 +0200 (CEST) Message-Id: <39740ACC.C1F6AF8D@ccrle.nec.de> Date: Tue, 18 Jul 2000 09:44:12 +0200 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en,de Mime-Version: 1.0 To: "Thomas D. Nadeau" Cc: iso@ptl.abk.nec.co.jp, myoshida@ptl.abk.nec.co.jp, ak@ccrle.nec.de, mpls@UU.NET, cheenu Srinivasan , arun@force10networks.com, Juergen Quittek , IETF Policy WG Subject: Re: draft-isoyama-policy-mpls-info-model-00.txt References: <4.3.2.7.2.20000717160707.00a94030@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Thomas, The answer is fairly the same than the one from Chadha. The information model works on a higher-level of abstraction than COPS-PR. The model is used in the policy server (refer to the Policy Framework). The communication between policy server and the network can be implemented via COPS or other means. From the information model point of view, it does not matter if the operation is online or offline, the only thing the model allows is the specification of rules applied to functions. Marcus "Thomas D. Nadeau" wrote: > > Hi, > > I asked these same questions earlier about another > draft which is related to defining an object model for > MPLS Policy. A few questions about your draft entitled, > "Policy Framework QoS Information Model for MPLS." > > 1) How does this draft differ from say the use > of COPS and the definition of a PIB > instead of using the object model? > > 2) It is not clear to me whether or not it is your > intent to make this object model useful > for both MPLS network management or just > only for off-line TE. It seems from reading > your document that your intent is to do > both. > > --Tom -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner New address starting 9/1/2000 Postal Mail: Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 905110 Fax: +49 (0)6221/ 9051155 Address valid until 8/31/2000 Postal Mail: Hardenbergplatz 2 D-10623 Berlin Germany Phone: +49 (0)30/ 25 42 30 17 Fax: +49 (0)30/ 25 42 30 99 From majordomo@raleigh.ibm.com Tue Jul 18 11:48:05 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27730 for ; Tue, 18 Jul 2000 11:48:04 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA25538; Tue, 18 Jul 2000 11:46:06 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA25668; Tue, 18 Jul 2000 11:46:05 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27780; Tue, 18 Jul 2000 11:23:44 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27766; Tue, 18 Jul 2000 11:23:40 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA23440 for ; Tue, 18 Jul 2000 11:23:41 -0400 Received: from brmnj-fw ([63.89.157.2]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id LAA30506 for ; Tue, 18 Jul 2000 11:23:37 -0400 Received: by BMAILNJ with Internet Mail Service (5.5.2650.21) id <3VY46JNS>; Tue, 18 Jul 2000 11:16:00 -0400 Message-Id: <6399122981E1D211AB490090271E0AA38B1DEF@BMAILNJ> From: "Francis Reichmeyer (IPHighway MA)" To: "'Thomas D. Nadeau '" , "'Ritu Chadha '" , "'policy@raleigh.ibm.com '" , "'mpls@UU.NET '" Cc: "'chadha@research.telcordia.com '" , "'hlin1@telcordia.com '" , "'mykoniat@research.telcordia.com '" Subject: RE: Policy Information Model for MPLS Traffic Engineering Date: Tue, 18 Jul 2000 11:15:55 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Francis Reichmeyer (IPHighway MA)" Tom, > I thought that the purpose of the MPLS WG was to define >protocols (and MIBs to manage them) not policy, but I may be >mistaken here. ;) From the Adelaide meeting minutes (regarding the presentation made on 'Requirements for Policy Enabled MPLS'): "... Moreover, George Swallow stated that policy and MPLS are two things that have very much in common and much to do with each other, so it is worth working on." I'm not sure that means policy is actually part of the purpose of the WG ;^) but it's worth considering. On a related note, we've submitted a draft on COPS usage for MPLS/TE that should be showing up on the repository any day now (submitted on Friday). It should come out as draft-franr-mpls-cops-00.txt. Looking forward to discussing it, PIBs and maybe even information models, in Pittsburgh. Thanks, -Fran From majordomo@raleigh.ibm.com Tue Jul 18 11:49:21 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28301 for ; Tue, 18 Jul 2000 11:49:19 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA16612; Tue, 18 Jul 2000 11:46:02 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA03336; Tue, 18 Jul 2000 11:46:02 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41748; Tue, 18 Jul 2000 11:16:55 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA27144; Tue, 18 Jul 2000 11:16:51 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA27516 for ; Tue, 18 Jul 2000 11:16:52 -0400 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA06252 for ; Tue, 18 Jul 2000 11:16:46 -0400 Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6IFG2R12822; Tue, 18 Jul 2000 11:16:02 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id LAA01097; Tue, 18 Jul 2000 11:16:01 -0400 (EDT) Message-Id: <200007181516.LAA01097@monday.research.telcordia.com> Date: Tue, 18 Jul 2000 11:16:01 -0400 (EDT) From: Ritu Chadha Subject: Re: Policy Information Model for MPLS Traffic Engineering To: policy@raleigh.ibm.com, mpls@UU.NET, tnadeau@cisco.com Cc: chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: XCJxrzhEvv1gau5jpMZvGw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ritu Chadha Tom, > Hi, > >>The definition of such policy information models is the >>whole raison d'etre of the Policy Framework WG. The following >>snippet from "Requirements for a Policy Management System", >>draft-ietf-policy-req-01.txt, >>summarizes the need for a standardized common information model: > > I thought that the purpose of the MPLS WG was to define >protocols (and MIBs to manage them) not policy, but I may be >mistaken here. ;) I can understand holding topological information >or such network-wide things, but the inclusion of other information >into this standard object model seems redundant, doesn't it? >Isn't this why we have the MIBs and PIBs? That is, to define >what is manageable, and how some of those managed objects are >provisioned via a defined policy? Why should we spend time >defining an object model which has basically already been >defined for MPLS? > > --Tom You may be right about this work not belonging to the MPLS WG. It may fit more naturally into the Policy WG. However, I thought it was appropriate to cross-post to both mailing lists because (a) we need to get feedback from the MPLS WG since that's where the subject matter experts are; and (b) there was a discussion about policy at the MPLS meeting in Adelaide where people agreed that MPLS policy work was of interest to this WG (this was during S. Wright's presentation of draft-wright-policy-mpls-00.txt). George Swallow stated that policy and MPLS are two things that have a lot in common and therefore was worth working on. The consensus in the WG seemed to be that contributions in this area should be brought to the MPLS WG. Ritu From majordomo@raleigh.ibm.com Tue Jul 18 13:00:27 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00769 for ; Tue, 18 Jul 2000 13:00:26 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA32212; Tue, 18 Jul 2000 12:58:57 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA25542; Tue, 18 Jul 2000 12:58:59 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37264; Tue, 18 Jul 2000 12:34:21 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21346; Tue, 18 Jul 2000 12:34:13 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA28406 for ; Tue, 18 Jul 2000 12:34:15 -0400 Received: from blsmsgims03.bls.com (iocfirewall2ext.bls.com [139.76.64.4]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA45318 for ; Tue, 18 Jul 2000 12:09:30 -0400 Received: from SMTP (blsmsgims03.bls.com [139.76.86.35]) by blsmsgims03.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PFLH3798; Tue, 18 Jul 2000 12:08:04 -0400 Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.35 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 18 Jul 2000 16:08:04 0000 (GMT) Received: from gf5142_gxsmlg (g0214070 [90.30.214.70]) by snt.bellsouth.com (8.9.1b+Sun/8.9.1) with SMTP id MAA27850; Tue, 18 Jul 2000 12:07:37 -0400 (EDT) From: "Steven Wright" To: "'Ritu Chadha'" , , , Cc: , , Subject: RE: Policy Information Model for MPLS Traffic Engineering Date: Tue, 18 Jul 2000 12:07:34 -0400 Message-Id: <001001bff0d2$49363170$46d61e5a@gf5142_gxsmlg.bst.bls.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200007181516.LAA01097@monday.research.telcordia.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Steven Wright" Content-Transfer-Encoding: 7bit Sending the information model to both groups seems the right thing to do for now, as both groups need some understanding of the progress of the work. I look forward to some interesting discussions in Pittsburgh on the appropriate scope of mpls working group documents related to the mpls policy topic. my 2c opinion - anything mpls specific belongs in the mpls wg, anything policy generic belongs in the policy wg. crosspost the stuff in the middle until we get some stable (RFC) documents to reference. regards Steven Wright > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Ritu > Chadha > Sent: Tuesday, July 18, 2000 11:16 AM > To: policy@raleigh.ibm.com; mpls@UU.NET; tnadeau@cisco.com > Cc: chadha@research.telcordia.com; hlin1@telcordia.com; > mykoniat@research.telcordia.com > Subject: Re: Policy Information Model for MPLS Traffic Engineering > > > Tom, > > > Hi, > > > >>The definition of such policy information models is the > >>whole raison d'etre of the Policy Framework WG. The following > >>snippet from "Requirements for a Policy Management System", > >>draft-ietf-policy-req-01.txt, > >>summarizes the need for a standardized common information model: > > > > I thought that the purpose of the MPLS WG was to define > >protocols (and MIBs to manage them) not policy, but I may be > >mistaken here. ;) I can understand holding topological information > >or such network-wide things, but the inclusion of other information > >into this standard object model seems redundant, doesn't it? > >Isn't this why we have the MIBs and PIBs? That is, to define > >what is manageable, and how some of those managed objects are > >provisioned via a defined policy? Why should we spend time > >defining an object model which has basically already been > >defined for MPLS? > > > > --Tom > > You may be right about this work not belonging to the MPLS WG. > It may fit more naturally into the Policy WG. However, I thought > it was appropriate to cross-post to both mailing lists because > (a) we need to get feedback from the MPLS WG since that's where the > subject matter experts are; and (b) there was a discussion about > policy at the MPLS meeting in Adelaide where people agreed that > MPLS policy work was of interest to this WG (this was during > S. Wright's presentation of draft-wright-policy-mpls-00.txt). > George Swallow stated that policy and MPLS are two things > that have a lot in common and therefore was worth working on. > The consensus in the WG seemed to be that contributions in > this area should be brought to the MPLS WG. > > Ritu > > > From majordomo@raleigh.ibm.com Tue Jul 18 14:17:44 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29717 for ; Tue, 18 Jul 2000 14:17:43 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA28170; Tue, 18 Jul 2000 14:15:20 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA04590; Tue, 18 Jul 2000 14:15:20 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44064; Tue, 18 Jul 2000 13:48:31 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43544; Tue, 18 Jul 2000 13:48:28 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA20426 for ; Tue, 18 Jul 2000 13:48:30 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA26398 for ; Tue, 18 Jul 2000 13:48:25 -0400 Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA08889; Tue, 18 Jul 2000 13:47:07 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-185.cisco.com [161.44.134.185]) by bucket.cisco.com (Mirapoint) with ESMTP id AAB03104; Tue, 18 Jul 2000 13:52:31 -0400 (EDT) Message-Id: <4.3.2.7.2.20000718132846.04ca00a0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2000 13:31:42 -0400 To: George Swallow , Ritu Chadha From: "Thomas D. Nadeau" Subject: Re: Policy Information Model for MPLS Traffic Engineering Cc: policy@raleigh.ibm.com, mpls@UU.NET, chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com, Walter Weiss In-Reply-To: <200007181624.MAA25662@lir.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Thomas D. Nadeau" Hi, I just want to add my 2 cents here. First, I agree as I have all along, that this stuff does not belong in the MPLS WG. Second, there is a BOF in Pittsburgh which is designed specifically to coordinate the specification of object models (for policy or otherwise). The BOF is called Network Information Modeling (NIM). You can join the discussion list by sending email to nim-req@ops.ietf.org I believe that Walter Weiss is coordinating the BOF. --Tom > > George Swallow stated that policy and MPLS are two things > > that have a lot in common and therefore was worth working on. > >There's a problem with sound bites. I also said that I didn't think >the work belonged in MPLS. > > > The consensus in the WG seemed to be that contributions in > > this area should be brought to the MPLS WG. > >I didn't agree with this consensus because the request was too general >and thus overlaps with other work groups. Though our revised charter >is still being worked out with the IESG, there will be no general >policy item in it. If specific items are needed in RSVP, LDP and >CR-LDP to glue things together, these are appropriate. > >Given that the MPLS agenda is tight, I would like both > > draft-chadha-policy-mpls-te-00.txt > draft-isoyama-policy-mpls-info-model-00.txt > >present only in the policy wg. > >...George > > >================================================================== >George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From majordomo@raleigh.ibm.com Wed Jul 19 09:43:29 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06007 for ; Wed, 19 Jul 2000 09:43:28 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA35224; Wed, 19 Jul 2000 09:41:17 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA35032; Wed, 19 Jul 2000 09:41:18 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29306; Wed, 19 Jul 2000 09:03:53 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48350; Wed, 19 Jul 2000 09:03:38 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA36976 for ; Wed, 19 Jul 2000 09:03:39 -0400 From: remoore@us.ibm.com Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.9) with SMTP id JAA26148 for ; Wed, 19 Jul 2000 09:03:38 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256921.0047BD45 ; Wed, 19 Jul 2000 09:03:35 -0400 X-Lotus-Fromdomain: IBMUS To: policy@raleigh.ibm.com Message-Id: <85256921.00479C54.00@d54mta02.raleigh.ibm.com> Date: Wed, 19 Jul 2000 09:00:52 -0400 Subject: Four Policy Framework WG I-Ds available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: remoore@us.ibm.com While they're finding their way into the IETF's Internet-Drafts repository, I've made the following four Policy documents available at the usual alternate location: ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/draft-ietf-policy-core-info-model-07.txt ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/draft-ietf-policy-core-schema-07.txt ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/draft-ietf-policy-terminology-00.txt ftp://ftp.networking.ibm.com/pub/standards/aiw/misc/draft-ietf-policy-qos-device-info-model-01.txt Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Wed Jul 19 10:23:06 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20934 for ; Wed, 19 Jul 2000 10:23:05 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA40620; Wed, 19 Jul 2000 10:21:41 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA21250; Wed, 19 Jul 2000 10:21:43 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23834; Wed, 19 Jul 2000 09:32:59 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37624; Wed, 19 Jul 2000 09:32:54 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA30896 for ; Wed, 19 Jul 2000 09:32:52 -0400 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA24038 for ; Wed, 19 Jul 2000 09:32:49 -0400 Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6JDVhR03335; Wed, 19 Jul 2000 09:31:43 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id JAA01658; Wed, 19 Jul 2000 09:31:43 -0400 (EDT) Message-Id: <200007191331.JAA01658@monday.research.telcordia.com> Date: Wed, 19 Jul 2000 09:31:43 -0400 (EDT) From: Ritu Chadha Subject: Re: Policy Information Model for MPLS Traffic Engineering To: swallow@cisco.com, chadha@research.telcordia.com, tnadeau@cisco.com Cc: policy@raleigh.ibm.com, mpls@UU.NET, chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com, wweiss@ellacoya.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: NtpeLvHjMBprkX0lKC7xnA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ritu Chadha Unfortunately, the draft agenda released yesterday shows that the NIM BOF clashes with the MPLS meeting on Wed morning... Ritu >X-Sender: tnadeau@bucket.cisco.com >Date: Tue, 18 Jul 2000 13:31:42 -0400 >To: George Swallow , Ritu Chadha >From: "Thomas D. Nadeau" >Subject: Re: Policy Information Model for MPLS Traffic Engineering >Cc: policy@raleigh.ibm.com, mpls@UU.NET, chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com, Walter Weiss >Mime-Version: 1.0 > > > Hi, > > I just want to add my 2 cents here. First, I >agree as I have all along, that this stuff does not belong >in the MPLS WG. Second, there is a BOF in Pittsburgh which >is designed specifically to coordinate the specification >of object models (for policy or otherwise). The BOF >is called Network Information Modeling (NIM). You >can join the discussion list by sending email to >nim-req@ops.ietf.org I believe that Walter Weiss >is coordinating the BOF. > > --Tom > >> > George Swallow stated that policy and MPLS are two things >> > that have a lot in common and therefore was worth working on. >> >>There's a problem with sound bites. I also said that I didn't think >>the work belonged in MPLS. >> >> > The consensus in the WG seemed to be that contributions in >> > this area should be brought to the MPLS WG. >> >>I didn't agree with this consensus because the request was too general >>and thus overlaps with other work groups. Though our revised charter >>is still being worked out with the IESG, there will be no general >>policy item in it. If specific items are needed in RSVP, LDP and >>CR-LDP to glue things together, these are appropriate. >> >>Given that the MPLS agenda is tight, I would like both >> >> draft-chadha-policy-mpls-te-00.txt >> draft-isoyama-policy-mpls-info-model-00.txt >> >>present only in the policy wg. >> >>...George >> >> >>================================================================== >>George Swallow Cisco Systems (978) 244-8143 >> 250 Apollo Drive >> Chelmsford, Ma 01824 > ============================================================================= Ritu Chadha Senior Scientist Telcordia Technologies (973) 829-4869 (voice) MCC 1J-218R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From majordomo@raleigh.ibm.com Thu Jul 20 11:55:25 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24738 for ; Thu, 20 Jul 2000 11:55:24 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA37702; Thu, 20 Jul 2000 11:53:45 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA28616; Thu, 20 Jul 2000 11:53:47 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA14744; Thu, 20 Jul 2000 11:13:22 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38282; Thu, 20 Jul 2000 11:13:18 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA28044 for ; Thu, 20 Jul 2000 11:13:21 -0400 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA27964 for ; Thu, 20 Jul 2000 11:13:16 -0400 Received: from yramberg-hpxu.cisco.com (telaviv3-dhcp65.cisco.com [144.254.93.193]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id SAA07132 for ; Thu, 20 Jul 2000 18:13:12 +0300 (IDT) Message-Id: <4.3.2.7.2.20000720171401.00dc15e0@csi-admin1.cisco.com> X-Sender: yramberg@csi-admin1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 18:09:41 -0500 To: policy@raleigh.ibm.com From: Yoram Ramberg Subject: Preliminary comments on draft-chadha-policy-mpls-te-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Yoram Ramberg Ritu, Huai-An and all - Great job! Your draft is well crafted and very clear. It's quite rare to see techies who can also write... I've done a quick review of this document and have a couple of comments. I'll limit my comments to the actual technical policy specification part as I'm a very little expert on MPLS. So most of my comments refer to the class definition itself. Also, due to time constraints, I've only done a partial review. So these are just a couple of things I stumbled over. I'm sure there will be more comments from others, feeling in the holes that I left. Now - 1. While this is addressed in part in the usage examples, it would be good to add text explaining how this object model fits in with a global policy object model in a practical, real life situation. In such a situation there will be a data tree made up of domains, policy groups, repositories and such. Should there be a chart and/or text describing this? 2. Naming: - Throughout the class definition each action class contains a name property. I think this may not be necessary because there's an elaborate naming mechanism already built into PolicyAction. - In some cases, when a class is derived from the Policy abstract class, it may be necessary to consider a name attribute, but please consult section 5.3 of the core inf. model for naming guidelines. 3. Multiple property definitions: Some properties are multiply defined -- Why? It appears that once you defined the mpTrafficTrunk reference property you don't need to redefine it every time it is used. The 'Name' property is also multiply defined but as I said above, it may not be necessary at all. 4. In general, it would be good to specify which properties are 'MUST' and which are merely 'MAY'. For example. it seems that the inf. model has several '*' associations. In such cases the reference property should be a 'MAY' property. 5. Referring to the MPLSResourceProfile class. Aren't these two PR traffic profiles? Say, mpInPolicer and mpOutPolicer, both referencing an instance of qosPolicyPRTrfcProf. Now, here's a good place to use the core style association classes (similar to MPLSHopInRoute and such) -- this is particularly important for an LDAP schema (assuming one would be created for this inf. model). Details can be made available upon request.] In any event, these should be references to reusable objects (IMO). 6. Referring to the association of MPLSTrafficTrunk and qosPolicyPRTrfcProf. I'm not too sure about that, but why limit yourself to the policer? Another approach would associate a trunk with a general PR action including a meter (with an interface scope) and such? Am I wrong on this? 7. Do you happen to have (or are willing to create) a UML chart in a format that's easier on the eye (Visio or such)? ASCII art is the standard but not always clear enough. Cheers, *Yoram From majordomo@raleigh.ibm.com Sun Jul 23 06:55:02 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17716 for ; Sun, 23 Jul 2000 06:55:01 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA42786; Sun, 23 Jul 2000 06:53:17 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA26044; Sun, 23 Jul 2000 06:53:19 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41678; Sun, 23 Jul 2000 06:31:56 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53904; Sun, 23 Jul 2000 06:31:13 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA21000 for ; Sun, 23 Jul 2000 06:31:16 -0400 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA15938 for ; Sun, 23 Jul 2000 06:31:11 -0400 Received: from yramberg-hpxu.cisco.com (telaviv3-dhcp65.cisco.com [144.254.93.193]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id NAA01891 for ; Sun, 23 Jul 2000 13:31:19 +0300 (IDT) Message-Id: <4.3.2.7.2.20000723123356.00dcf970@csi-admin1.cisco.com> X-Sender: yramberg@csi-admin1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 23 Jul 2000 13:05:59 -0500 To: policy@raleigh.ibm.com From: Yoram Ramberg Subject: Preliminary response to draft-isoyama-policy-mpls-info-model-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Yoram Ramberg All - I've read this draft and I think it is great. It takes a simpler approach to the problem than the other draft (draft-chadha-policy-mpls-te-00.txt), althought there are clear similarities. After all, there are only so many ways to skin this cat. Again, I'm no MPLS expert so I'm not going to comment on the actual semantics of LPS provisioning classes themselves (although it is quite clear to me how they fit in). It's very likely that the WG will ask the authors of both drafts to combine forces and merge their efforts so that the WG can adopt this and create a "draft-ietf-policy-mpls-..." document. We can't endorse two MPLS TE standards. For example, the Chadha documents contains construct to specify "backup" LSP provisioning. I don;t think this draft addresses this kind of policy. Here, as in the other draft there may be some issues in the actual class definition. For example, no property 'MAY'/'MUST' designation. I would also like to see some tect explaining the implication of decision strategy (fist-match/all-match) within a policy group. This draft allows for a direct utilization of QPIM's actions. It leaves implementors a lot of room to employ various technologies in enforcing the QoS policy over the LSPs. I like that. The example is very good and quite clear. I particularly liked the clear modeling of a complete policy rule. This shows clearly how to place policy rules for MPLS TE in the overall PCIM paradigm. In addition, the direct utilization of QPIM's constructs to profile traffic shines through the examples. I'd still like to see a couple of examples to model a bit more complex policy (to show that it can be done). I hope to meet the authors of both documents next week in the IETF gathering and talk to them some more about this. Thanx, *Yoram From majordomo@raleigh.ibm.com Tue Jul 25 11:23:43 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25278 for ; Tue, 25 Jul 2000 11:23:43 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA29770; Tue, 25 Jul 2000 11:22:06 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA27376; Tue, 25 Jul 2000 11:22:06 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23554; Tue, 25 Jul 2000 10:55:54 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21498; Tue, 25 Jul 2000 10:55:51 -0400 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA33098 for ; Tue, 25 Jul 2000 10:55:52 -0400 From: Ed_Ellesson@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id JAA09351 for ; Tue, 25 Jul 2000 09:55:21 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256927.0051F8D4 ; Tue, 25 Jul 2000 09:55:21 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Message-Id: <86256927.0051F876.00@tivmta4.tivoli.com> Date: Tue, 25 Jul 2000 10:56:32 -0400 Subject: I-D ACTION:draft-ietf-policy-qos-device-info-model-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com Note that qos device model draft is available now in the I-D repository. Ed Ellesson Tivoli Systems Research Triangle Park, NC ed_ellesson@tivoli.com 919-224-2111 ---------------------- Forwarded by Ed Ellesson/Tivoli Systems on 07/25/2000 10:54 AM --------------------------- policy-owner@raleigh.ibm.com on 07/25/2000 06:38:12 AM From nsyracus@cnri.reston.va.us Tue Jul 25 06:38:08 2000 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44214; Tue, 25 Jul 2000 06:38:08 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA35190 for ; Tue, 25 Jul 2000 06:38:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA22936 for ; Tue, 25 Jul 2000 06:38:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24605; Tue, 25 Jul 2000 06:38:05 -0400 (EDT) Message-Id: <200007251038.GAA24605@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: policy@raleigh.ibm.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-policy-qos-device-info-model-01.txt Date: Tue, 25 Jul 2000 06:38:04 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Policy Framework Working Group of the IETF. Title : Information Model for Describing Network Device QoS Mechanisms Author(s) : J. Strassner, A. Westerinen, B. Moore Filename : draft-ietf-policy-qos-device-info-model-01.txt Pages : 63 Date : 24-Jul-00 The purpose of this draft is to define an information model that describes the QoS mechanisms inherent in different network devices. Broadly speaking, these mechanisms describe the attributes common to selecting and conditioning traffic through the forwarding path of network devices running Differentiated Services (see [R2475]). The next version of this draft will also address Integrated Services (see [R1633]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-info-model-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-policy-qos-device-info-model-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-policy-qos-device-info-model-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000724142606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-policy-qos-device-info-model-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-policy-qos-device-info-model-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000724142606.I-D@ietf.org> --OtherAccess-- --NextPart-- From majordomo@raleigh.ibm.com Fri Jul 28 15:36:09 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23922 for ; Fri, 28 Jul 2000 15:36:08 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA20520; Fri, 28 Jul 2000 15:33:32 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA29840; Fri, 28 Jul 2000 15:33:32 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52084; Fri, 28 Jul 2000 15:09:40 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41324; Fri, 28 Jul 2000 15:09:37 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA24916 for ; Fri, 28 Jul 2000 15:09:43 -0400 Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA19076 for ; Fri, 28 Jul 2000 15:09:40 -0400 Received: from andreawlap (atlantis-dial-1-124.cisco.com [171.68.181.125]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id MAA17646; Fri, 28 Jul 2000 12:09:06 -0700 (PDT) From: "Andrea Westerinen" To: Cc: "Ed Ellesson" , "John Strassner" , "Remoore@Us. Ibm. Com" Subject: Correction to the QoS Device Info Model Draft Date: Fri, 28 Jul 2000 12:12:46 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit The current authors of want to apologize to Walter Weiss and Dave Durham for omitting their names from the authors list. Walter and Dave were authors on Rev 00 of this draft. The omission was unintentional (due to job changes and submission deadlines) and will be corrected in the next rev of the document. Our apologies, Andrea, John and Bob From majordomo@raleigh.ibm.com Sat Jul 29 14:22:28 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29530 for ; Sat, 29 Jul 2000 14:22:27 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA09224; Sat, 29 Jul 2000 14:20:31 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA36374; Sat, 29 Jul 2000 14:20:32 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA36658; Sat, 29 Jul 2000 13:56:31 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46376; Sat, 29 Jul 2000 13:56:28 -0400 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA33256 for ; Sat, 29 Jul 2000 13:56:28 -0400 From: Ed_Ellesson@tivoli.com Received: from tivmta4.tivoli.com (tivmta4.tivoli.com [146.84.104.47]) by corp.tivoli.com (8.9.3/8.9.0) with SMTP id MAA09770; Sat, 29 Jul 2000 12:55:43 -0500 (CDT) Received: by tivmta4.tivoli.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625692B.00627B7C ; Sat, 29 Jul 2000 12:55:41 -0500 X-Lotus-Fromdomain: TIVOLI SYSTEMS To: policy@raleigh.ibm.com Cc: steven.wright@snt.bellsouth.com, iso@ptl.abk.nec.co.jp, chadha@research.telcordia.com, Yves.TJoens@Alcatel.be, iyer@internetdevices.com, johns@cisco.com, randy@psg.com, bwijnen@lucent.com, ed_ellesson@tivoli.com, Robert_Moore/Raleigh/IBM@tivoli.com, andreaw@cisco.com, david.durham@intel.com, wweiss@ellacoya.com, agenda@ietf.org Message-Id: <8625692B.00627AE3.00@tivmta4.tivoli.com> Date: Sat, 29 Jul 2000 13:54:05 -0400 Subject: Proposed agenda for Policy WG meetings in Pittsburgh Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ed_Ellesson@tivoli.com Dear patient policy people: Sorry for lateness of posting this agenda. Time is allocated at the beginning of the first day to bash it. This agenda has not yet been finalized with the AD's or the presenters, and is subject to change. Proposed Strawman Policy Agenda Monday, 1530-1730: ----------------------------- 1. 15 min. Ed and John: agenda bash 2. 20 min: Bob Moore or John Strassner: IESG Last Call review results, and resulting policy info model (PCIM) changes, See: draft-ietf-policy-core-info-model-07.txt 3. 20 min: Bob Moore: Policy Schema (PCLS) mapping techniques applied to PCIM, what's new. See: draft-ietf-policy-core-schema-07.txt 4. 60 min. John Strassner, et al: qos policy device model: what's new See: draft-ietf-policy-qos-device-info-model-01.txt 5. 5 min. Ed: wrap-up for today Tuesday, 1545-1800: ------------------------------- 1. 5 min. Ed: Review agenda: 2. 15 min: Andrea Westerinen: polterm status See: draft-ietf-policy-terminology-00.txt 3. 40 min: Various. mpls applications of the policy model. Note: Three groups of authors have posted a total of 5 drafts related to this topic, and some of these authors have requested time on the agenda. Time is hereby allocated to allow short (10 min. each) presentations, one presentation by each of the author groups, plus a short discussion period after all three, to help us understand the implications of these approaches for how the policy model is being applied and extended, and how it relates to the charter of this group (we will also come back to the charter at the end). See: draft-chadha-policy-mpls-te-00.txt draft-isoyama-policy-mpls-info-model-00.txt draft-wright-policy-mpls-00.txt draft-wright-mpls-te-policy-00.txt draft-wright-load-distribution-00.txt 4. 10 min. Mahadevan Iyer: vpn policy: presentation on positioning this work relative to policy model and ipsp work See: draft-iyer-policy-ipvpn-info-model-00.txt 5. 10 min. Yves T'Joens : Service Level Specification Semantics for DiffServ, presentation on relevance to policy model See: draft-tequila-diffserv-sls-00.txt 6. 45 min. Ed and John: Charter Items and schedule for going forward 7. 10 min. Ed Wrapup . Ed and John From majordomo@raleigh.ibm.com Sun Jul 30 16:03:48 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04748 for ; Sun, 30 Jul 2000 16:03:47 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA29628; Sun, 30 Jul 2000 15:58:42 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA33048; Sun, 30 Jul 2000 15:58:43 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23742; Sun, 30 Jul 2000 15:32:20 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA31384; Sun, 30 Jul 2000 15:32:12 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA25326 for ; Sun, 30 Jul 2000 15:32:14 -0400 Received: from mailhost.iitb.ac.in (mailhost.iitb.ac.in [203.197.74.142]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id PAA31076 for ; Sun, 30 Jul 2000 15:32:10 -0400 Received: (qmail 16866 invoked from network); 30 Jul 2000 19:41:10 -0000 Received: from surya.cse.iitb.ernet.in (144.16.111.14) by mailhost.iitb.ac.in with SMTP; 30 Jul 2000 19:41:10 -0000 Received: from everest.cse.iitb.ernet.in (sunil@everest [144.16.111.4]) by surya.cse.iitb.ernet.in (8.8.8/8.8.8) with ESMTP id AAA05937 for ; Mon, 31 Jul 2000 00:59:04 +0530 (IST) Received: from localhost (sunil@localhost) by everest.cse.iitb.ernet.in (8.9.2/8.9.2) with ESMTP id AAA01937 for ; Mon, 31 Jul 2000 00:55:35 +0530 (IST) Date: Mon, 31 Jul 2000 00:55:34 +0530 (IST) From: Yarram V Sunil Kumar To: policy@raleigh.ibm.com Subject: policy condition Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Yarram V Sunil Kumar Hi, I am new to this group. I read the draft "Policy core information model", in this draft it is mentioned that the policy condition should be either a CNF or DNF, what are the advantages in representing the conditions in the above forms. Consider the case, if there is some language used to describe the policies in which the network manager can have the choice to give the condition neither in CNF or DNF then the conversion to CNF or DNF may increase overhead. In short i want to know the motivation behind the representation of policy condition in CNF or DNF. -Sunil. ####################################################################### Y V SUNIL KUMAR HOSTEL-1 M.Tech, IIT BOMBAY ROOM NO 262 sunil@cse.iitb.ernet.in IIT BOMBAY sun_y_v@mailexcite.com Powai,Mumbai-76. ####################################################################### Buy a Pentium 586/90 so you can reboot faster.