idnits 2.17.1 draft-ietf-dmm-fpc-cpdp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 6, 2015) is 3214 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '16' on line 425 == Missing Reference: 'Carrier ID' is mentioned on line 424, but not defined == Missing Reference: 'Network ID' is mentioned on line 425, but not defined -- Looks like a reference, but probably isn't: '32' on line 428 == Missing Reference: 'Client ID' is mentioned on line 418, but not defined == Missing Reference: 'Agent ID' is mentioned on line 422, but not defined == Missing Reference: 'DPN ID' is mentioned on line 426, but not defined == Missing Reference: 'Event ID' is mentioned on line 428, but not defined == Missing Reference: 'DSCP' is mentioned on line 448, but not defined == Missing Reference: 'GBR' is mentioned on line 473, but not defined == Missing Reference: 'MBR' is mentioned on line 478, but not defined == Missing Reference: 'DPN2' is mentioned on line 728, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7333 ** Downref: Normative reference to an Informational RFC: RFC 7429 -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group M. Liebsch 3 Internet-Draft NEC 4 Intended status: Standards Track S. Matsushima 5 Expires: January 7, 2016 SoftBank 6 S. Gundavelli 7 Cisco 8 D. Moses 9 Intel Corporation 10 July 6, 2015 12 Protocol for Forwarding Policy Configuration (FPC) in DMM 13 draft-ietf-dmm-fpc-cpdp-01.txt 15 Abstract 17 The specification as per this document supports the separation of the 18 Control-Plane for mobility- and session management from the actual 19 Data-Plane. The protocol semantics abstract from the actual details 20 for the configuration of Data-Plane nodes and apply between a Client 21 function, which is used by an application of the mobility Control- 22 Plane, and an Agent function, which is associated with the 23 configuration of Data-Plane nodes according to the policies issued by 24 the mobility Control-Plane. The scope of the policies comprises 25 forwarding rules and treatment of packets in terms of encapsulation, 26 IP address re-writing and QoS. Additional protocol semantics are 27 described to support the maintenance of the Data-Plane path. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 7, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 65 3. Model for Policy-based DMM Network Control . . . . . . . . . 3 66 3.1. Reference Architecture for DMM Forwarding Policy 67 Configuration . . . . . . . . . . . . . . . . . . . . . . 3 68 3.2. Generalized Rules on the Client-Agent-Interface . . . . . 6 69 3.3. Role of the DMM FPC Client Function . . . . . . . . . . . 6 70 3.4. Role of the DMM FPC Agent Function . . . . . . . . . . . 7 71 4. Protocol Messages and Semantics . . . . . . . . . . . . . . . 7 72 4.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 7 73 4.2. Protocol Attributes . . . . . . . . . . . . . . . . . . . 9 74 4.3. Protocol Operation . . . . . . . . . . . . . . . . . . . 13 75 5. Conceptual Data Structures . . . . . . . . . . . . . . . . . 18 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 8. Work Team Participants . . . . . . . . . . . . . . . . . . . 19 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 81 9.2. Informative References . . . . . . . . . . . . . . . . . 19 82 Appendix A. YANG Data Model for the FPC Protocol . . . . . . . . 20 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 85 1. Introduction 87 One objective of the Distributed Mobility Management (DMM) WG is the 88 separation of the mobility management Control- and Data-Plane to 89 enable flexible deployment, such as decentralized provisioning of 90 Data-Plane nodes (DPN). Data-Plane nodes can be configured to 91 function as anchor for a registered Mobile Node's (MN) traffic, 92 others can be configured to function as Mobile Access Gateway (MAG) 93 as per the Proxy Mobile IPv6 protocol [RFC5213] or a Foreign Agent 94 (FA) as per the Mobile IPv4 protocol [RFC3344]. Requirements for DMM 95 have been described in [RFC7333], whereas best current practices for 96 DMM are documented in [RFC7429]. 98 The Data-Plane must provide a set of functions to the Mobility 99 Control-Plane, such as support for encapsulation, IP address re- 100 writing, QoS differentiation and traffic shaping. In addition, the 101 configuration of forwarding rules must be provided. These 102 requirements are met by various transport network components, such as 103 IP switches and routers, though configuration semantics differs 104 between them. 106 Forwarding Policy Configuration (FPC) as per this document enables 107 the configuration of any Data-Plane node and type by the abstraction 108 of configuration details and the use of common configuration 109 semantics. The protocol using the FPC semantics is deployed between 110 a Client function, which is associated with the Mobility Management 111 Control-Plane, and an Agent function. The Agent function enforces 112 the Data-Plane configuration and can be present on a transport 113 network controller or co-located with a Data-Plane node. The Agent 114 applies the generalized configuration semantics to configuration, 115 which is specific to the Data-Plane node and type. The Mobility 116 Control-Plane can select one or multiple DPNs which suit the MN's 117 mobility management without the need to handle each node's routing- 118 or switching tables and local interface configurations for 119 potentially many routers serving the Data-Plane, but enforce the 120 policies for traffic treatment and forwarding through the FPC Client 121 and the FPC Agent functions. 123 2. Conventions and Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Model for Policy-based DMM Network Control 131 3.1. Reference Architecture for DMM Forwarding Policy Configuration 133 The DMM Forwarding Policy Configuration (FPC) protocol enables DMM 134 use cases in deployments with separated Control-/Data-Plane and is 135 used by applications of the Mobility Control-Plane to enforce rules 136 for forwarding and traffic treatment in the Data-Plane. Figure 1 137 depicts an exemplary use case where downlink traffic from a 138 Correspondent Node (CN) towards a Mobile Node (MN) traverses multiple 139 DPNs, each applying policies as per the Control-Plane's request. 140 Policies in the one or multiple DPNs can result in traffic steering 141 according to a host-route, packet scheduling and marking according to 142 a subscriber's QoS profile, or forwarding rules (e.g. encapsulation 143 within GRE or GTP-U tunnel). 145 +--------------------------+ 146 | Mobility Control | 147 +--------------------------+ 148 | | | 149 | | | 150 | | | 151 \ / V V V 152 +--+ -o- +---+ +---+ +---+ +--+ 153 |MN| ---- |---|DPN|<========|DPN|<----|DPN|<--|CN| 154 +--+ | +---+ +---+ +---+ +--+ 155 Rules: Rules: Rules: 156 Decap, Encap, host-route 157 Forward Forward, 158 qos 160 Figure 1: Exemplary illustration of a use case for DMM traffic 161 steering and policy enforcement at Data Plane Nodes (DPN) 163 Mobility Control-Plane functions have the following roles in common: 165 o Tracking an MN's location 167 o Accept requests to set up and maintain mobility-related Data-Plane 168 path between DPNs, taking QoS attributes into account. Such 169 requests can be issued through mobility protocols, such as Proxy 170 Mobile IPv6, and the associated operation with remote Mobility 171 Control-Plane functions. 173 o Become aware of different DPNs that provide the required Data- 174 plane functions to the Mobility Control-Plane and can be used for 175 mobility traffic forwarding and treatment 177 o Monitor the DPNs' operation and handle exceptions, e.g. the 178 detection of a partial DPN failure and the diversion of traffic 179 through a different DPN 181 o Maintain consistency between multiple DPNs which enforce policy 182 rules for an MN 184 Mobility Data-Plane functions have the following roles in common: 186 o Forward and treat traffic according to the policies and directives 187 sent by the Mobility Control-Plane 189 o Provide status (e.g. load, health, statistics and traffic volume) 190 information on request 192 o Participate in the process for topology acquisition, e.g. by 193 exposing relevant topological and capability information, such as 194 support for QoS differentiation and supported encapsulation 195 protocols 197 The protocol for DMM FPC applies to the interface between an FPC 198 Client function and an FPC Agent function, as depicted in Figure 2. 199 The FPC Client function is associated with an application function of 200 the mobility management Control-Plane, e.g. a Local Mobility Anchor 201 Control-Plane function as per the Proxy Mobile IPv6 protocol. The 202 FPC Agent function processes the FPC protocol semantics and 203 translates them into configuration commands as per the DPN's 204 technology. In one example, an FPC Agent can be co-located with a 205 Transport Network Controller, which enforces forwarding rules on a 206 set of SDN switches. In another example, the Agent can be co-located 207 with a single router to directly interact with interface management 208 and the router's RIB Manager. The mapping of the common FPC 209 semantics and policy description as per this specification to the 210 configuration commands of a particular DPN is specific to the DPN's 211 technology and the Agent's implementation. 213 +-------------------------+ 214 | Mobility Control-Plane | 215 | | 216 |+--------[API]----------+| 217 || FPC Client Function || 218 |+----------^------------+| 219 +-----------|-------------+ 220 | 221 | DMM FPC protocol 222 | 223 +-----------|-------------+ 224 |+----------v------------+| 225 || FPC Agent Function || 226 |+-----------------------+| 227 | | 228 | DPN Configuration API | 229 +-------------------------+ 231 Figure 2: Illustration of the functional reference architecture for 232 DMM Forwarding Policy Configuration (FPC) 234 3.2. Generalized Rules on the Client-Agent-Interface 236 To abstract configuration details of an IP switch or IP router on the 237 FPC protocol interface, this specification adopts the model of 238 logical Ports to bind certain properties, such as a QoS policy. 239 Additional properties can be bound to the same logical Port, e.g. 240 encapsulation of packets, being directed to that logical Port, in a 241 GRE tunnel. The remote tunnel endpoint is configured as part of the 242 property bound to that logical Port. All traffic, which has a 243 forwarding rule in common and should be forwarded according to the 244 properties bound to a particular Port, can be referred to that Port 245 by configuration of a forwarding rule. Multiple IP flows or even 246 aggregated traffic being destined to a given IP prefix can be 247 directed to that logical Port and experiences the same treatment 248 according to the configured properties and forwarding 249 characteristics. Aggregated or per-Host/per-Flow traffic can be 250 identified by a longest prefix match or a Traffic Selector [RFC6088] 251 respectively. 253 Figure 3 illustrates the generic policy configuration model as used 254 between an FPC Client function and an FPC Agent function. 256 +-------------------+ 257 | Bind 1..M | 258 | | | traffic templates | 259 | | | | to each logical | 260 | | | | port | 261 | | | +-------------------+ 262 v v v 263 --------------- ... [logical ports space] 264 | | | 265 +--PROP_1.1 +--PROP_2.1 +--PROP_3.1 +-------------------+ 266 | | | Bind 1..N | 267 +--PROP_1.2 +--PROP_3.2 | properties | 268 | | to each logical | 269 +--PROP_1.3 | port | 270 +-------------------+ 272 Figure 3: Illustration of generalized rules 274 3.3. Role of the DMM FPC Client Function 276 The DMM FPC Client function includes the following tasks: 278 o Per mobility management transaction or relevant event, build one 279 or multiple Control messages/attributes to control policies on one 280 or multiple DPA(s) according to the application's directives 282 o Treat a DPN's policy rules (encapsulation, address re-write, QoS, 283 traffic monitoring) on the basis of properties being bound to 284 logical ports (similar to the bearer concept in cellular networks) 286 o Build, modify or delete logical ports as needed 288 o Bind associated policy rules as one or multiple properties to a 289 logical port 291 o Treat forwarding rules (e.g. per-IP flow, per-MN, per-IP, per- 292 prefix) on the basis of logical ports 294 o Send each generated message to the DMM FPC Agent associated with 295 the identified DPN 297 o Keep record of the policy rules/port information and the 298 associated DPN and FPC Agent Function 300 o Process received Response, Notification and Query messages issued 301 by a DMM FPC Agent Function and notify the application 303 3.4. Role of the DMM FPC Agent Function 305 The DMM FPC Agent function includes the following tasks: 307 o Process the received Control messages issued by a DMM FPC Client 308 Function 310 o Unambiguously match each logical port with an associated physical 311 port or interface at the identified DPN 313 o Apply the received properties to local configuration (e.g. 314 encapsulation, NA(P)T, traffic prioritization and scheduling) on 315 the identified DPN according to the DPN's technology 317 o Monitor scheduled events (e.g. failure or missing rule) and issue 318 an associated message to the FPC Client Function (NOTIFICATION, 319 QUERY) 321 4. Protocol Messages and Semantics 323 4.1. Protocol Messages 325 The following table lists all specified protocol messages to create 326 and delete logical Ports, to add properties and to add forwarding 327 rules in terms of binding traffic descriptors to a logical Port. 328 Furthermore, messages are specified to schedule tasks, such as 329 monitoring, at an Agent and to probe the status of the scheduled task 330 from a Client. Additional messages are specified to enable the Data- 331 Plane to notify or query the Control-Plane through the Agent and 332 Client functions. 334 +---------------------------------------------------------------------+ 335 | Message | Description | 336 +=====================================================================+ 337 | Messages issued by the FPC Client | 338 +---------------------------------------------------------------------+ 339 | PRT_ADD | Add a logical port | 340 +---------------------------------------------------------------------+ 341 | PRT_DEL | Delete an existing logical port | 342 +---------------------------------------------------------------------+ 343 | PROP_ADD | Add a property to a logical port | 344 +---------------------------------------------------------------------+ 345 | PROP_MOD | Modify a property of a logical port | 346 +---------------------------------------------------------------------+ 347 | PROP_DEL | Remove and delete a property from a logical port | 348 +---------------------------------------------------------------------+ 349 | RULE_ADD | Add forwarding rule by binding traffic descriptor | 350 | | to a logical port | 351 +---------------------------------------------------------------------+ 352 | RULE_MOD | Modify existing forwarding rule by changing the | 353 | | traffic descriptor bound to a logical port | 354 +---------------------------------------------------------------------+ 355 | RULE_DEL | Delete a forwarding rule | 356 +---------------------------------------------------------------------+ 357 | EVENT_REG | Register an event and descriptions at an Agent | 358 | | about what is to be monitored by the Agent and | 359 | | what is to be reported in case the event occurs | 360 +---------------------------------------------------------------------+ 361 | PROBE | Probe the status of a registered event | 362 +---------------------------------------------------------------------+ 363 | Messages issued by the FPC Agent | 364 +---------------------------------------------------------------------+ 365 | | Notify the Client about the status of a | 366 | NOTIFY | monitored attribute at any event kind | 367 | | (periodic / event trigger / probed) | 368 +---------------------------------------------------------------------+ 369 | QUERY | Query the Client about missing rules/states | 370 +---------------------------------------------------------------------+ 372 Figure 4: Protocol Messages 374 4.2. Protocol Attributes 376 Protocol messages as per Section 4.1 carry attributes to identify an 377 FPC Client- or Agent function, as well as a DPN, logical ports and 378 configuration data. Furthermore, attributes are carried to manage 379 logical ports and describe properties associated with a logical port, 380 as well as to describe per-host-, aggregate or IP flow traffic and 381 refer to a logical port as forwarding information. 383 This document specifies attributes from the following categories: 385 o Identifier attributes 387 o Properties 389 o Property-specific attributes 391 o Rules and Traffic descriptors 393 Note on the list of attributes: The list of attributes is not yet 394 complete. 396 Note on Format Clarification: Meant to provide an idea on the content 397 of attributes. Semantics of key information fields or sub-option and 398 the value's length (bit) are indicated. The possibility of a field/ 399 option to appear multiple times in a message or within an attribute, 400 e.g. as sub-option, is referred to by '*'. 402 +---------------------------------------------------------------------+ 403 | Attribute | Format Clarification | Description | 404 +=====================================================================+ 405 | Identifiers | 406 +---------------------------------------------------------------------+ 407 | PRT_ID | [32,PRT_ID] | Identifies a logical Port | 408 +---------------------------------------------------------------------+ 409 | PRT_PROP_ID | [32,PRT_ID] | Identifies a logical Port | 410 | | [8,PROP_ID] | and one of its properties | 411 +---------------------------------------------------------------------+ 412 | PRT_RULE_ID | [32,PRT_ID] | Identifies a logical Port | 413 | | [8,RULE_ID] | and a rule that refers to | 414 | | | the Port | 415 +----------------+----------------------+-----------------------------+ 416 | CLI_ID | [16, Carrier ID] | Identifies an | 417 | | [16, Network ID] | FPC Client function | 418 | | [32, Client ID] | | 419 +---------------------------------------------------------------------+ 420 | AGT_ID | [16, Carrier ID] | Identifies an | 421 | | [16, Network ID] | FPC Agent function | 422 | | [32, Agent ID] | | 423 +---------------------------------------------------------------------+ 424 | DPN_ID | [16, Carrier ID] | Identifies a Data Plane | 425 | | [16, Network ID] | Node (DPN) | 426 | | [32, DPN ID] | | 427 +---------------------------------------------------------------------+ 428 | EVENT_ID | [32, Event ID] |Identifies a registered event| 429 +---------------------------------------------------------------------+ 431 Figure 5: Protocol Attributes: Identifiers 433 +----------------------------------------------------------------------+ 434 | Attribute | Format Clarification | Description | 435 +======================================================================+ 436 | Properties | 437 +----------------------------------------------------------------------+ 438 | PROP_TUN | [type][src][dst] | Property Encapsulation, | 439 | | | indicates type GRE, IP, | 440 | | | GTP | 441 +----------------------------------------------------------------------+ 442 | PROP_REWR | [in_src_ip][out_src_ip] | Property NAT defines | 443 | | [in_dst_ip][out_dst_ip] | IP address and port | 444 | | [in_src_port][out_src_port]| re-write rules | 445 | | [in_dst_port][out_dst_port]| | 446 +----------------------------------------------------------------------+ 447 | PROP_QOS | [QoS index type][index] | Property QoS refers to | 448 | | [DSCP] | single index and DS Code| 449 | | | Point to write | 450 +----------------------------------------------------------------------+ 451 | PROP_GW | [ip address next hop] | IP address of the Next | 452 | | | Hop to which IP packets | 453 | | | should be forwarded | 454 +----------------------------------------------------------------------+ 456 Figure 6: Protocol Attributes: Properties 458 +---------------------------------------------------------------------+ 459 | Attribute | Format Clarification | Description | 460 +=====================================================================+ 461 | Property-specific | 462 +---------------------------------------------------------------------+ 463 | IPIP_CONF | | IP-encapsulation | 464 | | | configuration attribute | 465 +---------------------------------------------------------------------+ 466 | GRE_CONF | [prototype][seq-#] | GRE_encapsulation | 467 | | [key] | configuration attribute | 468 +---------------------------------------------------------------------+ 469 | GTP_CONF | [TEID_local] | GTP-U encapsulation | 470 | | [TEID_remote] | configuration attribute | 471 | | [seq-#] | | 472 +---------------------------------------------------------------------+ 473 | QOS_GBR | [GBR] *[PRT_ID] | Guaranteed Bit Rate and | 474 | | | single or multiple PRT_IDs | 475 | | | to which the GBR applies | 476 | | | when being aggregated | 477 +----------------+----------------------+-----------------------------+ 478 | QOS_MBR | [MBR] *[PRT_ID] | Maximum Bit Rate and single | 479 | | | or multiple PRT_IDs to which| 480 | | | the MBR applies when being | 481 | | | aggregated | 482 +----------------+----------------------+-----------------------------+ 484 Figure 7: Protocol Attributes: Property-specific 486 +---------------------------------------------------------------------+ 487 | Attribute | Format Clarification | Description | 488 +=====================================================================+ 489 | Rules | 490 +---------------------------------------------------------------------+ 491 | RULE_DST_IP | [IP address] | Aggregated or per-host dst | 492 | | [Prefix Len] | IP address/prefix rule | 493 +---------------------------------------------------------------------+ 494 | RULE_SRC_IP | [IP address] | Aggregated or per-host src | 495 | | [Prefix Len] | IP address/prefix rule | 496 +---------------------------------------------------------------------+ 497 | RULE_TS | [Traffic Selector] | Traffic Selector based rule,| 498 | | | Format as per RFC6088 | 499 +----------------+----------------------+-----------------------------+ 501 Figure 8: Protocol Attributes: Rules 503 4.3. Protocol Operation 505 The following list comprises a more detailed description of each 506 message's semantic. 508 o PRT_ADD - Issued by a Client to add a new logical port at an 509 Agent, to which traffic can be directed. An Agent receiving the 510 PRT_ADD message should identify the new logical port according to 511 the included port identifier (PRT_ID). The Agent should add a new 512 logical port into its conceptual data structures using the port 513 identifier as key. Optionally, the PRT_ADD message can include 514 property descriptions as well as rules descriptions, which are 515 bound and refer to the new logical port. This enables a Client to 516 issue a new configuration in a single transaction with an Agent. 518 o PRT_DEL - Used by a Client to delete an existing logical port. An 519 Agent receiving such message should delete all properties 520 associated with the identified port. 522 o PROP_ADD - Used by the Client to add a new property to an existing 523 logical port. The property is unambiguously identified through a 524 property identifier (PRT_PROP_ID). All traffic, which is directed 525 to this logical port, experiences the existing and newly added 526 property. Optionally, the PROP_ADD message can include rules 527 descriptions, which refer to the port to which the properties are 528 bound. This enables a Client to add new rules to the existing 529 port to which the new properties have been bound in a single 530 transaction. 532 o PROP_MOD - Used by a Client to modify an existing property. For 533 example, a tunnel property can be changed to direct traffic to a 534 different tunnel endpoint in case of an MN's handover. 535 Optionally, the PROP_MOD message can include rules descriptions, 536 which refer to the port whose properties are modified. This 537 enables a Client to add new rules to the existing port whose 538 properties have been modifier in a single transaction. 540 o PROP_DEL - Used by a Client to delete one or multiple properties, 541 each being identified by a property identifier. 543 o RULE_ADD - Used by a Client to add a forwarding rule and direct 544 traffic towards a logical port. The rule add command must 545 unambiguously identify aggregated traffic (longest prefix), per 546 host IP traffic or per-flow traffic in the RULE_ADD command and 547 bind the identified traffic to a logical port. An Agent receiving 548 a RULE_ADD command must add the rule to its local conceptual data 549 structures and apply commands for local configuration to add the 550 new forwarding rule on the DPN. Multiple forwarding rules, each 551 identifying different traffic, can direct traffic to the same 552 logical port. All traffic being directed to this logical port 553 will then experience the same properties. 555 o RULE_MOD - Used by a Client to modify an existing forwarding rule. 556 An Agent receiving such message should apply commands for local 557 configuration to update the forwarding rule on the DPN. 559 o RULE_DEL - Used to delete an existing forwarding rule on a DPN. 560 The Agent receiving such message should delete the rules from its 561 local conceptual data structures and apply commands for local 562 configuration to remove the forwarding rule on the DPN. 564 o EVENT_REG - Used by a Client to register an attribute, which is to 565 be monitored, at an Agent. The EVENT_REG provides an attribute to 566 the Agent as well as a reporting kind. The Agent should register 567 the event and an event identifier in the local conceptual data 568 structures. The Agent should start monitoring the registered 569 attribute (e.g. load) and notify the Client about the status 570 according to the registered reporting kind (periodic, event 571 trigger, probed). In case of a periodic reporting kind, the Agent 572 should report the status of the attribute each configured interval 573 using a NOTIFY message. The reporting interval is provided with 574 the EVENT_REG message. In case of an event triggered reporting 575 kind, the Agent should report the status of the attribute in case 576 of a triggered event, e.g. the monitored attribute's value exceeds 577 a given threshold. The threshold is provided with the EVENT_REG 578 message. In case of probed reporting, the Agent receives a PROBE 579 message and should report the status of a monitored attributes to 580 the Client by means of a NOTIFY message. 582 o PROBE - Used by a Client to retrieve information about a 583 previously registered event. The PROBE message should identify 584 one or more events by means of including the associated event 585 identifier. An Agent receiving a PROBE message should send the 586 requested information for each event in a single or multiple 587 NOTIFY messages. 589 o NOTIFY - Used by an Agent to report the status of an event to a 590 Client. 592 o QUERY - Used by an Agent to request an update of logical port 593 properties via a Client. 595 The following list provides some information on the use and semantics 596 of attributes: 598 o PROP_TUN - Defines the properties for encapsulation into different 599 tunnel headers. The property includes IP address information of 600 tunnel endpoints as well as a type identifier to select the 601 encapsulation type. Further attributes may be included to provide 602 information which is relevant for the configuration and 603 initialization of the tunnel. 605 o PROP_REWR - Defines the properties for IP address and port re- 606 write. 608 o PROP_QOS - Defines the QoS properties in terms of a known index 609 type, e.g. LTE's Quality Class Index (QCI), and its value (QCI 610 1..9), as well as a Differentiated Services Code Point (DSCP) to 611 classify and mark packets. Additional attributes may follow, e.g. 612 as sub-options, to define Guaranteed Bit Rate (GBR) and Maximum 613 Bit Rate (MBR) bounds. GBR and MBR attributes can apply to a 614 single port or multiple ports. The latter is required to 615 configure aggregate bounds, such as Aggregate Maximum Bit Rate 616 (AMBR), taking traffic, which is forwarded through different ports 617 (hence experiencing different treatment), into account. In such 618 case the GBR/MBR attributes append multiple PRT_ID attributes to 619 identify the ports which are to be monitored to determine the 620 aggregated view of the bit rate. The scope of attributes for QoS 621 is aligned to [RFC7222]. The Allocation and Retention Priority 622 (ARP) as per [RFC7222] is not present in the list of QoS-specific 623 attributes, since ARP is treated and kept in the Control-Plane for 624 granting requests for new resources and QoS, as well as for 625 preempting other QoS configuration, if needed. 627 o PROP_GW - Defines a Next Hop IP address, to which packets are 628 forwarded. Using this attribute, the Control-Plane can configure 629 a host-route in the Data-Plane to deviate from default routes. 631 Figure 9 illustrates an exemplary session life-cycle based on Proxy 632 Mobile IPv6 registration via MAG Control-Plane function 1 (MAG-C1) 633 and handover to MAG Control-Plane function 2 (MAG-C2). Edge DPN1 634 represents the Proxy CoA after attachment, whereas Edge DPN2 serves 635 as Proxy CoA after handover. 637 +-------Router--------+ 638 +-----------+ |+-------+ +---------+| 639 +------+ +------+ +-----+ FPC | | FPC | | Anchor | 640 |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN | 641 +------+ +------+ +-----+-------+ +-------+ +---------+ 642 [MN attach] | | | | 643 |-------------PBU----->| | | 644 | | |----(1)-PRT_ADD---------->| | 645 | | | [PRT_ID] | | 646 | | | | | 647 | | |--(2)---PROP_ADD--------->| | 648 | | | [PROP_ID,PROP_TUN] |--tun1 up->| 649 | | | | | 650 | | |--(3)---PROP_ADD--------->| | 651 | | | [PROP_ID,PROP_QOS] |--tc qos-->| 652 |<------------PBA------|--(4)----RULE_ADD-------->| | 653 | +----+ | | [HNP,PRT_ID] |-route add>| 654 | |Edge| | | | | 655 | |DPN1| | | | | 656 | +----+ | | | | 657 | | | 658 | |-=======================================================-| 659 | | | | 660 | [MN handover] | | | 661 | |---PBU ---->| | | 662 | | |--(5)---PROP_MOD--------->| | 663 | |<--PBA------| [PROP_ID,PROP_TUN] |-tun1 mod->| 664 | | | | | 665 | | +----+ | | | 666 | | |Edge| | | | 667 | | |DPN2| | | | 668 | | +----+ | | | 669 | | | | | | 670 | | |-============================================-| 671 | | | | | 673 Figure 9: Exemplary Message Sequence (focus on FPC reference point) 675 After reception of the Proxy Binding Update (PBU) at the LMA Control- 676 Plane function (LMA_C), the LMA-C selects a suitable DPN, which 677 serves as Data-Plane anchor to the MN's traffic. The LMA-C adds a 678 new logical port to the DPN to treat the MN's traffic (1) and 679 includes a Port Identifier (PRT_ID) to the PRT_ADD command. The 680 LMA-C identifies the selected Anchor DPN by including the associated 681 DPN identifier. 683 Subsequently, the LMA-C adds properties to the new logical port. One 684 property is added (2) to specify the forwarding tunnel type and 685 endpoints (Anchor DPN, Edge DPN1). Another property is added (3) to 686 specify the QoS differentiation, which the MN's traffic should 687 experience. At reception of the properties, the FPC Agent calls 688 local router commands to enforce the tunnel configuration (tun1) as 689 well as the traffic control (tc) for QoS differentiation. After 690 configuration of port properties have been completed, the LMA can 691 configure the enforcement of the MN's traffic by adding a rule 692 (RULE_ADD) to forward traffic destined to the MN's HNP to the new 693 logical port (4). At the reception of the forwarding rule, the Agent 694 applies a new route to forward all traffic destined to the MN's HNP 695 to the configured tunnel interface (tun1). 697 During handover, the LMA-C receives an updating PBU from the handover 698 target MAG-C2. The PBU refers to a new Data-Plane node (Edge DPN2) 699 to represent the new tunnel endpoint. The LMA-C sends a PROP_MOD 700 message (5) to the Agent to modify the existing tunnel property of 701 the existing logical port and to update the tunnel endpoint from Edge 702 DPN1 to Edge DPN2. At reception of the PROP_MOD message, the Agent 703 applies local configuration commands to modify the tunnel. 705 To reduce the number of protocol handshakes between the LMA-C and the 706 DPN, the LMA-C can append property (PROP_TUN, PROP_QOS) and rules 707 (prefix info HNP) attributes to the PRT_ADD message, as illustrated 708 in Figure 10 709 +-----------+ +-------+ +---------+ 710 +------+ +------+ +-----+ FPC | | FPC | | Anchor | 711 |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN | 712 +------+ +------+ +-----+-------+ +-------+ +---------+ 713 [MN attach] | | | | 714 |-------------PBU----->| | | 715 | | |----(1)-PRT_ADD----------->| | 716 | | | [PRT_ID,PROP_ID,PROP_TUN, |--tun1 up->| 717 |<------------PBA------| PROP_ID,PROP_QOS, |--tc qos-->| 718 | | | HNP] |-route add>| 719 | [Edge]-=====================================================-| 720 | [DPN1| | | | | 721 | | | | | 722 | [MN handover] | | | 723 | |---PBU ---->| | | 724 | | |---------PROP_MOD--------->| | 725 | |<--PBA------| [PROP_ID,PROP_TUN] |-tun1 mod->| 726 | | | | | 727 | | [Edge]-===========================================-| 728 | | [DPN2] | | | 730 Figure 10: Example: Sequence for Message Aggregation (focus on FPC 731 reference point) 733 5. Conceptual Data Structures 735 An FPC Client must keep record about the logical ports, each port's 736 properties as well as configured rules as per the Mobility Control- 737 Plane function's request. Such information must be maintained for 738 each Agent, with which the Client communicates. In case the Mobility 739 Control-Plane function identifies a particular DPN at which the 740 policies should be enforced, the Client must associate the DPN 741 identifier with the logical port configuration. 743 According to the FPC Agent's role, the Agent translates the 744 generalized model for policy configuration and forwarding rules into 745 semantics and commands for local configuration, which is specific to 746 a DPN. Keeping a local record of DPN configuration attributes/values 747 is implementation specific and out of scope of this document. 749 Description of detailed data structures and information to be 750 recorded and maintained by an FPC Client and an FPC Agent are TBD and 751 will be added to a revision of this initial document. 753 6. Security Considerations 755 Detailed protocol implementations for DMM Forwarding Policy 756 Configuration must ensure integrity of the information exchanged 757 between an FPC Client and an FPC Agent. Required Security 758 Associations may be derived from co-located functions, which utilize 759 the FPC Client and FPC Agent respectively. 761 7. IANA Considerations 763 This document provides an information model for DMM Forwarding Policy 764 Configuration. Detailed protocol specifications for DMM Forwarding 765 Policy Configuration will follow the information model as per this 766 document and can be based on, for example, ReST-like or binary 767 protocol formats. Such protocol-specific details will be described 768 in separate documents and may require IANA actions. 770 8. Work Team Participants 772 Participants in the FPSM work team discussion include Satoru 773 Matsushima, Danny Moses, Sri Gundavelli, Marco Liebsch, Pierrick 774 Seite, Alper Yegin, Carlos Bernardos, Charles Perkins and Fred 775 Templin. 777 9. References 779 9.1. Normative References 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, March 1997. 784 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 785 "Traffic Selectors for Flow Bindings", RFC 6088, January 786 2011. 788 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 789 "Requirements for Distributed Mobility Management", RFC 790 7333, August 2014. 792 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 793 Bernardos, "Distributed Mobility Management: Current 794 Practices and Gap Analysis", RFC 7429, January 2015. 796 9.2. Informative References 798 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 799 August 2002. 801 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 802 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 804 [RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. 805 Gundavelli, "Quality-of-Service Option for Proxy Mobile 806 IPv6", RFC 7222, May 2014. 808 Appendix A. YANG Data Model for the FPC Protocol 810 This appendix provides (so far experimental) formating of some FPC 811 protocol components adopting YANG data modeling. The current FPC 812 information model as per this initial draft version will experience 813 extensions, as it is not yet complete, and may experience changes 814 that need to be reflected in the data model. Whether a detailed data 815 model will be included in this document or solely an information 816 model will be adopted by this document and a detailed data model will 817 be part of a separate document is currently being discussed. 819 file "ietf-dmm-fpcp@2015-07-06.yang" 821 module ietf-dmm-fpcp { 822 namespace "urn:ietf:params:xml:ns:yang:ietf-dmm-fpcp"; 823 prefix fpcp; 825 import ietf-inet-types { prefix inet; } 827 organization "IETF DMM Working Group"; 828 contact "Satoru Matsushima "; 830 description 831 "This module contains YANG definition for 832 Forwarding Policy Configuration Protocol.(FPCP)"; 834 revision 2015-07-06 { 835 description "Changes based on -01 version of FPCP draft."; 836 reference "draft-ietf-dmm-fpc-cpdp-01"; 837 } 839 typedef fpcp-port-id { 840 type uint32; 841 description "PRT_ID"; 842 } 844 typedef fpcp-property-id { 845 type uint8; 846 description "PRT_PROP_ID"; 848 } 850 typedef fpcp-rule-id { 851 type uint8; 852 description "PRT_RULE_ID"; 853 } 855 identity tunnel-type { 856 description 857 "Base identity from which specific use of 858 tunnels are derived."; 859 } 861 identity fpcp-tunnel-type { 862 base "tunnel-type"; 863 description 864 "Base identity from which specific tunnel 865 types in FPCP uses are derived."; 866 } 868 identity ip-in-ip { 869 base "fpcp-tunnel-type"; 870 description "IP-in-IP tunnel"; 871 } 873 identity gtp { 874 base "fpcp-tunnel-type"; 875 description "GTP-U tunnel"; 876 } 878 identity gre { 879 base "fpcp-tunnel-type"; 880 description "GRE tunnel"; 881 } 883 identity service-function { 884 description 885 "Base identity from which specific 886 service function types are derived."; 887 } 889 identity ip-protocol { 890 description 891 "Base identity from which specific 892 IP protocol types are derived."; 893 } 895 identity qos-type { 896 description 897 "Base identity from which specific 898 uses of QoS types are derived."; 899 } 901 identity fpcp-qos-type { 902 base "qos-type"; 903 description 904 "Base identity from which specific 905 QoS types in FPCP uses are derived."; 906 } 908 identity fpcp-qos-type-gbr { 909 base "fpcp-qos-type"; 910 description 911 "A QoS Type for Guaranteed Bit Rate (GBR)."; 912 } 914 identity fpcp-qos-type-mbr { 915 base "fpcp-qos-type"; 916 description 917 "A QoS Type for Maximum Bit Rate (MBR)."; 918 } 920 grouping fpcp-client { 921 description "CLI_ID to identify FPCP Client"; 922 leaf carrier-id { 923 type uint16; 924 description "Carrier ID"; 925 } 926 leaf network-id { 927 type uint16; 928 description "Network ID"; 929 } 930 leaf client-id { 931 type uint32; 932 mandatory true; 933 description "Client ID"; 934 } 935 } 937 grouping fpcp-agent { 938 description "AGT_ID to identify FPCP Agent"; 939 leaf carrier-id { 940 type uint16; 941 description "Carrier ID"; 942 } 943 leaf network-id { 944 type uint16; 945 description "Network ID"; 946 } 947 leaf agent-id { 948 type uint32; 949 mandatory true; 950 description "Agent ID"; 951 } 952 } 954 grouping dpn { 955 description "DPN_ID to identify Data-Plane Node"; 956 leaf carrier-id { 957 type uint16; 958 description "Carrier ID"; 959 } 960 leaf network-id { 961 type uint16; 962 description "Network ID"; 963 } 964 leaf dpn-id { 965 type uint32; 966 mandatory true; 967 description "DPN ID"; 968 } 969 } 971 grouping tunnel-endpoints { 972 description 973 "PROP_TUN property as a set of tunnel endpoints"; 974 leaf tunnel-type { 975 type identityref { 976 base "fpcp-tunnel-type"; 977 } 978 description "Tunnel Type"; 979 } 980 leaf remote-address { 981 type inet:ip-address; 982 description "Remote endpoint"; 983 } 984 leaf local-address { 985 type inet:ip-address; 986 description "Local endpoint"; 987 } 988 } 990 grouping gtp-attributes { 991 description 992 "GTP_CONF as GTP tunnel specific attributes"; 993 leaf remote-teid { 994 type uint32; 995 description "TEID of remote-endpoint"; 996 } 997 leaf local-teid { 998 type uint32; 999 description "TEID of local-endpoint"; 1000 } 1001 } 1003 grouping gre-attributes { 1004 description 1005 "GRE_CONF as GRE tunnel specific attribute"; 1006 leaf key { 1007 type uint32; 1008 description "GRE_KEY"; 1009 } 1010 } 1012 grouping rewriting-properties { 1013 description 1014 "PROP_REWR. TBD for which type of rewriting functions 1015 need to be defined"; 1016 leaf type { 1017 type identityref { 1018 base service-function; 1019 } 1020 description "The type of service-function"; 1021 } 1022 } 1024 grouping qos-properties { 1025 description "PROP_QOS"; 1026 leaf qos-type { 1027 type identityref { 1028 base "fpcp-qos-type"; 1029 } 1030 description "QoS Type"; 1031 } 1032 leaf bandwidth { 1033 type uint32; 1034 description ""; 1035 } 1036 } 1038 grouping fpcp-identifier-attributes { 1039 description 1040 "Identifiers of protocol attributes"; 1041 container client { 1042 description "Client ID"; 1043 uses fpcp-client; 1044 } 1045 container agent { 1046 description "Agent ID"; 1047 uses fpcp-agent; 1048 } 1049 list nodes { 1050 key dpn-id; 1051 uses dpn; 1052 description "DPN ID"; 1053 } 1054 } 1056 grouping fpcp-traffic-descriptor { 1057 description 1058 "Traffic descriptor group collects parameters to 1059 identify target traffic flow."; 1060 leaf rule-id { 1061 type fpcp-rule-id; 1062 description "PRT_RULE_ID"; 1063 } 1064 leaf destination-ip { 1065 type inet:ip-prefix; 1066 description "Rule of destination IP"; 1067 } 1068 leaf source-ip { 1069 type inet:ip-prefix; 1070 description "Rule of source IP"; 1071 } 1072 leaf protocol { 1073 type identityref { 1074 base "ip-protocol"; 1075 } 1076 description "Rule of protocol"; 1077 } 1078 leaf destination-port { 1079 type inet:port-number; 1080 description "Rule of destination port"; 1081 } 1082 leaf source-port { 1083 type inet:port-number; 1084 description "Rule of source port"; 1085 } 1086 } 1087 grouping fpcp-port-properties { 1088 description 1089 "A set of port property attributes"; 1090 leaf property-id { 1091 type fpcp-property-id; 1092 description "Property ID"; 1093 } 1094 container endpoints { 1095 description "Tunnel Endpoint"; 1096 uses tunnel-endpoints; 1097 } 1098 container qos { 1099 description "QoS Type"; 1100 uses qos-properties; 1101 } 1102 container rewriting { 1103 description "Rewriting function"; 1104 uses rewriting-properties; 1105 } 1106 choice tunnel { 1107 description "Tunnel-Type"; 1108 case gtp-u { 1109 when "tunnel-type = 'gtp'" { 1110 description "In case of GTP-U is tunnel-type"; 1111 } 1112 uses gtp-attributes; 1113 } 1114 case gre { 1115 when "tunnel-type = 'gre'" { 1116 description "In case of GRE is tunnel-type"; 1117 } 1118 uses gre-attributes; 1119 } 1120 } 1121 } 1123 // Port Entries 1125 container port-entries { 1126 description 1127 "This container binds set of traffic-descriptor and 1128 port properties to a port and lists them as a port entry."; 1129 list port-entry { 1130 key port-id; 1131 description "List of port entries"; 1132 leaf port-id { 1133 type fpcp-port-id; 1134 description "Port-ID"; 1136 } 1137 container identifier { 1138 description "Attributes set of Identifiers"; 1139 uses fpcp-identifier-attributes; 1140 } 1141 list trafic-descriptor { 1142 key rule-id; 1143 description "Rule and traffic-descriptor"; 1144 uses fpcp-traffic-descriptor; 1145 } 1146 list properties { 1147 key property-id; 1148 description "Attributes set of properties"; 1149 uses fpcp-port-properties; 1150 } 1151 } 1152 } 1154 // PRT_ADD 1156 rpc port_add { 1157 description "PRT_ADD"; 1158 input { 1159 list adding-ports { 1160 description "Ports that are added to an agent"; 1161 leaf port-id { 1162 type fpcp-port-id; 1163 description "Port-ID"; 1164 } 1165 container trafic-descriptor { 1166 description "Rule and traffic-descriptor"; 1167 uses fpcp-traffic-descriptor; 1168 } 1169 list properties { 1170 key property-id; 1171 description "Attributes set of properties"; 1172 uses fpcp-port-properties; 1173 } 1174 } 1175 } 1176 } 1178 // PRT_DEL 1180 rpc port_delete { 1181 description "PRT_DEL"; 1182 input { 1183 list deleting-ports { 1184 description "Ports that are deleted from an agent"; 1185 leaf deleting-port { 1186 type fpcp-port-id; 1187 description "Deleting port-id"; 1188 } 1189 } 1190 } 1191 } 1193 // PROP_ADD 1195 rpc port_property_add { 1196 description "PROP_ADD"; 1197 input { 1198 list adding-properties { 1199 description "Properties that are added to an agent"; 1200 leaf target-port { 1201 type fpcp-port-id; 1202 description "Port-ID"; 1203 } 1204 list properties { 1205 key property-id; 1206 description "Attributes set of properties"; 1207 uses fpcp-port-properties; 1208 } 1209 } 1210 } 1211 } 1213 // PROP_MOD 1215 rpc port_property_modify { 1216 description "PROP_MOD"; 1217 input { 1218 list modifying-properties { 1219 description 1220 "Properties that are modified in an agent"; 1221 leaf target-port { 1222 type fpcp-port-id; 1223 mandatory true; 1224 description 1225 "Target port-id of modifying properties"; 1226 } 1227 list properties { 1228 key property-id; 1229 description "Attributes set of properties"; 1230 uses fpcp-port-properties; 1232 } 1233 } 1234 } 1235 } 1237 // PROP_DEL 1239 rpc port_property_delete { 1240 description "PROP_DEL"; 1241 input { 1242 list deleting-property { 1243 description 1244 "Target port/property-id of deleting properties"; 1245 leaf port-id { 1246 type fpcp-port-id; 1247 mandatory true; 1248 description "Port ID"; 1249 } 1250 leaf property-id { 1251 type fpcp-property-id; 1252 mandatory true; 1253 description "Property ID"; 1254 } 1255 } 1256 } 1257 } 1259 // RULE_ADD 1261 rpc rule_add { 1262 description 1263 "TBD for input parameters of which RULE_ADD includes 1264 but now just traffic-descriptor."; 1265 input { 1266 list adding-rules { 1267 description "Rules that are added to an agent"; 1268 leaf target-port { 1269 type fpcp-port-id; 1270 mandatory true; 1271 description "Target port-id of adding rule"; 1272 } 1273 list port-rules { 1274 description "Added rule"; 1275 uses fpcp-traffic-descriptor; 1276 } 1277 } 1278 } 1279 } 1280 // RULE_MOD 1282 rpc rule_modify { 1283 description 1284 "TBD for input parameters of which RULE_MOD includes 1285 but now just traffic-descriptor."; 1286 input { 1287 list modifying-rules { 1288 description "Rules that are modified in an agent"; 1289 leaf target-port { 1290 type fpcp-port-id; 1291 mandatory true; 1292 description "Target port-id of modifying rule"; 1293 } 1294 list port-rule { 1295 description "Modified rule"; 1296 uses fpcp-traffic-descriptor; 1297 } 1298 } 1299 } 1300 } 1302 // RULE_DEL 1304 rpc rule_delete { 1305 description 1306 "TBD for input parameters of which RULE_DEL includes 1307 but now just traffic-descriptor."; 1308 input { 1309 list deleting-rules { 1310 description "Rules that are deleted from an agent"; 1311 leaf target-port { 1312 type fpcp-port-id; 1313 mandatory true; 1314 description "Target port-id of deleting rule"; 1315 } 1316 list target-rules { 1317 description "Deleting rules"; 1318 leaf target-rule-id { 1319 type fpcp-rule-id; 1320 mandatory true; 1321 description "Rule ID"; 1322 } 1323 } 1324 } 1325 } 1326 } 1327 // EVENT_REG 1329 rpc event_register { 1330 description 1331 "TBD for registered parameters included in EVENT_REG."; 1332 } 1334 // PROBE 1336 rpc probe { 1337 description 1338 "TBD for retrieved parameters included in PROBE."; 1339 } 1341 // NOTIFY 1343 notification notify { 1344 description 1345 "TBD for which status and event are reported to client."; 1346 } 1347 } 1349 1351 Figure 11: FPC YANG Data Model 1353 Authors' Addresses 1355 Marco Liebsch 1356 NEC Laboratories Europe 1357 NEC Europe Ltd. 1358 Kurfuersten-Anlage 36 1359 D-69115 Heidelberg 1360 Germany 1362 Phone: +49 6221 4342146 1363 Email: liebsch@neclab.eu 1365 Satoru Matsushima 1366 SoftBank 1367 1-9-1,Higashi-Shimbashi,Minato-Ku 1368 Tokyo 105-7322 1369 Japan 1371 Email: satoru.matsushima@g.softbank.co.jp 1372 Sri Gundavelli 1373 Cisco 1374 170 West Tasman Drive 1375 San Jose, CA 95134 1376 USA 1378 Email: sgundave@cisco.com 1380 Danny Moses 1382 Email: danny.moses@intel.com