idnits 2.17.1 draft-ietf-dmm-fpc-cpdp-00.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 (May 6, 2015) is 3275 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: '8' on line 408 == Missing Reference: 'Carrier ID' is mentioned on line 407, but not defined == Missing Reference: 'Network ID' is mentioned on line 408, but not defined -- Looks like a reference, but probably isn't: '16' on line 411 == Missing Reference: 'Client ID' is mentioned on line 401, but not defined == Missing Reference: 'Agent ID' is mentioned on line 405, but not defined == Missing Reference: 'DPN ID' is mentioned on line 409, but not defined == Missing Reference: 'Event ID' is mentioned on line 411, but not defined == Missing Reference: 'DPN2' is mentioned on line 631, 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 (~~), 9 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: November 7, 2015 Softbank Telecom 6 S. Gundavelli 7 Cisco 8 D. Moses 9 Intel Corporation 10 May 6, 2015 12 Protocol for Forwarding Policy Configuration (FPC) in DMM 13 draft-ietf-dmm-fpc-cpdp-00.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 November 7, 2015. 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 . . . . . . . . . . . . . . . . . . . 8 74 4.3. Protocol Operation . . . . . . . . . . . . . . . . . . . 10 75 5. Conceptual Data Structures . . . . . . . . . . . . . . . . . 15 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 8. Work Team Participants . . . . . . . . . . . . . . . . . . . 16 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 9.2. Informative References . . . . . . . . . . . . . . . . . 16 82 Appendix A. YANG Data Model for the FPC Protocol . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 gates (Ports) to bind certain properties, such as a QoS 239 policy. Additional properties can be bound to the same logical Port, 240 e.g. encapsulation of packets, being directed to that logical Port, 241 in a GRE tunnel. The remote tunnel endpoint is configured as part of 242 the 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 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 324 +---------------------------------------------------------------------+ 325 | Message | Description | 326 +=====================================================================+ 327 | Messages issued by the FPC Client | 328 +---------------------------------------------------------------------+ 329 | PRT_ADD | Add a logical port | 330 +---------------------------------------------------------------------+ 331 | PRT_DEL | Delete an existing logical port | 332 +---------------------------------------------------------------------+ 333 | PROP_ADD | Add a property to a logical port | 334 +---------------------------------------------------------------------+ 335 | PROP_MOD | Modify a property of a logical port | 336 +---------------------------------------------------------------------+ 337 | PROP_DEL | Remove and delete a property from a logical port | 338 +---------------------------------------------------------------------+ 339 | RULE_ADD | Add forwarding rule by binding traffic descriptor | 340 | | to a logical port | 341 +---------------------------------------------------------------------+ 342 | RULE_MOD | Modify existing forwarding rule by changing the | 343 | | traffic descriptor bound to a logical port | 344 +---------------------------------------------------------------------+ 345 | RULE_DEL | Delete a forwarding rule | 346 +---------------------------------------------------------------------+ 347 | EVENT_REG | Register an event at an Agent, which is to be | 348 | | monitored by the Agent and to be reported | 349 +---------------------------------------------------------------------+ 350 | PROBE | Probe the status of a registered event | 351 +---------------------------------------------------------------------+ 352 | Messages issued by the FPC Agent | 353 +---------------------------------------------------------------------+ 354 | | Notify the Client about the status of a | 355 | NOTIFY | monitored attribute at any event kind | 356 | | (periodic / event trigger / probed) | 357 +---------------------------------------------------------------------+ 358 | QUERY | Query the Client about missing rules/states | 359 +---------------------------------------------------------------------+ 361 Figure 4: Protocol Messages 363 4.2. Protocol Attributes 365 Protocol messages as per Section 4.1 carry attributes to identify an 366 FPC Client- or Agent function, as well as a DPN, logical ports and 367 configuration data. Furthermore, attributes are carried to manage 368 logical ports and describe properties associated with a logical port, 369 as well as to describe per-host-, aggregate or IP flow traffic and 370 refer to a logical port as forwarding information. 372 This document specifies attributes from the following categories: 374 o Identifier attributes 376 o Properties 378 o Property-specific attributes 380 o Traffic descriptors 382 Note on the list of attributes: The list of attributes is not yet 383 complete. 385 Note on Format Clarification: Meant to provide a first idea on the 386 format and number space and indicates length (bit) and semantics of 387 key information fields. 389 +---------------------------------------------------------------------+ 390 | Attribute | Format Clarification | Description | 391 +=====================================================================+ 392 | Identifiers | 393 +---------------------------------------------------------------------+ 394 | PRT_ID | [16,PTR_ID] | Identifies a logical Port | 395 +---------------------------------------------------------------------+ 396 | PRT_PROP_ID | [16,PRT_ID] | Identifies a logical Port | 397 | | [8,PROP_ID] | and one of its properties | 398 +---------------------------------------------------------------------+ 399 | CLI_ID | [8, Carrier ID] | Identifies an | 400 | | [8, Network ID] | FPC Client function | 401 | | [16, Client ID] | | 402 +---------------------------------------------------------------------+ 403 | AGT_ID | [8, Carrier ID] | Identifies an | 404 | | [8, Network ID] | FPC Agent function | 405 | | [16, Agent ID] | | 406 +---------------------------------------------------------------------+ 407 | DPN_ID | [8, Carrier ID] | Identifies a Data Plane | 408 | | [8, Network ID] | Node (DPN) | 409 | | [16, DPN ID] | | 410 +---------------------------------------------------------------------+ 411 | EVENT_ID | [16, Event ID] |Identifies a registered event| 412 +---------------------------------------------------------------------+ 414 Figure 5: Protocol Attributes: Identifiers 416 +---------------------------------------------------------------------+ 417 | Attribute | Format Clarification | Description | 418 +=====================================================================+ 419 | Properties | 420 +---------------------------------------------------------------------+ 421 | PROP_TUN | [type][src][dst] | Property Encapsulation, | 422 | | | indicates type GRE, IP, GTP | 423 +---------------------------------------------------------------------+ 424 | PROP_REWR | TBD | Property NAT | 425 +---------------------------------------------------------------------+ 426 | PROP_QOS | TBD | Property QoS | 427 +---------------------------------------------------------------------+ 428 | PROP_GW | [ip address next hop]| Property Next Hop | 429 +---------------------------------------------------------------------+ 431 Figure 6: Protocol Attributes: Properties 433 +---------------------------------------------------------------------+ 434 | Attribute | Format Clarification | Description | 435 +=====================================================================+ 436 | Property-specific | 437 +---------------------------------------------------------------------+ 438 | IPIP_CONF | | IP-encapsulation | 439 | | | configuration attribute | 440 +---------------------------------------------------------------------+ 441 | GRE_CONF | [prototype][seq-#] | GRE_encapsulation | 442 | | [key].. | configuration attribute | 443 +---------------------------------------------------------------------+ 444 | GTP_CONF | [TEID_local] | GTP-U encapsulation | 445 | | [TEID_remote] | configuration attribute | 446 | | [seq-#].. | | 447 +---------------------------------------------------------------------+ 449 Figure 7: Protocol Attributes: Property-specific 451 4.3. Protocol Operation 453 The following list comprises a more detailed description of each 454 message's semantic. 456 o PRT_ADD - Issued by a Client to add a new logical port at an 457 Agent, to which traffic can be directed. An Agent receiving the 458 PRT_ADD message should identify the new logical port according to 459 the included port identifier (PRT_ID). In case the DPN holds 460 already a registration for a logical port with the same 461 identifier, the Agent should throw an error message to the Client. 462 Otherwise the Agent should add a new logical port into its 463 conceptual data structures using the port identifier as key. 465 o PRT_DEL - Used by a Client to delete an existing logical port. An 466 Agent receiving such message should delete all properties 467 associated with the identified port. 469 o PROP_ADD - Used by the Client to add a new property to an existing 470 logical port. The property is unambiguously identified through a 471 property identifier (PRT_PROP_ID). All traffic, which is directed 472 to this logical port, experiences the existing and newly added 473 property. 475 o PROP_MOD - Used by a Client to modify an existing property. For 476 example, a tunnel property can be changed to direct traffic to a 477 different tunnel endpoint in case of an MN's handover 479 o PROP_DEL - Used by a Client to delete one or multiple properties, 480 each being identified by a property identifier. 482 o RULE_ADD - Used by a Client to add a forwarding rule and direct 483 traffic towards a logical port. The rule add command must 484 unambiguously identify aggregated traffic (longest prefix), per 485 host IP traffic or per-flow traffic in the RULE_ADD command and 486 bind the identified traffic to a logical port. An Agent receiving 487 a RULE_ADD command must add the rule to its local conceptual data 488 structures and apply commands for local configuration to add the 489 new forwarding rule on the DPN. Multiple forwarding rules, each 490 identifying different traffic, can direct traffic to the same 491 logical port. All traffic being directed to this logical port 492 will then experience the same properties. 494 o RULE_MOD - Used by a Client to modify an existing forwarding rule. 495 An Agent receiving such message should apply commands for local 496 configuration to update the forwarding rule on the DPN. 498 o RULE_DEL - Used to delete an existing forwarding rule on a DPN. 499 The Agent receiving such message should delete the rules from its 500 local conceptual data structures and apply commands for local 501 configuration to remove the forwarding rule on the DPN. 503 o EVENT_REG - Used by a Client to register an attribute, which is to 504 be monitored, at an Agent. The EVENT_REG provides an attribute to 505 the Agent as well as a reporting kind. The Agent should register 506 the event and an event identifier in the local conceptual data 507 structures. The Agent should start monitoring the registered 508 attribute (e.g. load) and notify the Client about the status 509 according to the registered reporting kind (periodic, event 510 trigger, probed). In case of a periodic reporting kind, the Agent 511 should report the status of the attribute each configured interval 512 using a NOTIFY message. The reporting interval is provided with 513 the EVENT_REG message. In case of an event triggered reporting 514 kind, the Agent should report the status of the attribute in case 515 of a triggered event, e.g. the monitored attribute's value exceeds 516 a given threshold. The threshold is provided with the EVENT_REG 517 message. In case of probed reporting, the Agent receives a PROBE 518 message and should report the status of a monitored attributes to 519 the Client by means of a NOTIFY message. 521 o PROBE - Used by a Client to retrieve information about a 522 previously registered event. The PROBE message should identify 523 one or more events by means of including the associated event 524 identifier. An Agent receiving a PROBE message should send the 525 requested information for each event in a single or multiple 526 NOTIFY messages. 528 o NOTIFY - Used by an Agent to report the status of an event to a 529 Client. 531 o QUERY - Used by an Agent to request an update of logical port 532 properties via a Client. 534 Figure 8 illustrates an exemplary session life-cycle based on Proxy 535 Mobile IPv6 registration via MAG Control-Plane function 1 (MAG-C1) 536 and handover to MAG Control-Plane function 2 (MAG-C2). Edge DPN1 537 represents the Proxy CoA after attachment, whereas Edge DPN2 serves 538 as Proxy CoA after handover. 540 +-------Router--------+ 541 +-----------+ |+-------+ +---------+| 542 +------+ +------+ +-----+ FPC | | FPC | | Anchor | 543 |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN | 544 +------+ +------+ +-----+-------+ +-------+ +---------+ 545 [MN attach] | | | | 546 |-------------PBU----->| | | 547 | | |----(1)-PRT_ADD---------->| | 548 | | | [PRT_ID] | | 549 | | | | | 550 | | |--(2)---PROP_ADD--------->| | 551 | | | [PROP_ID,PROP_TUN] |--tun1 up->| 552 | | | | | 553 | | |--(3)---PROP_ADD--------->| | 554 | | | [PROP_ID,PROP_QOS] |--tc qos-->| 555 |<------------PBA------|--(4)----RULE_ADD-------->| | 556 | +----+ | | [HNP,PRT_ID] |-route add>| 557 | |Edge| | | | | 558 | |DPN1| | | | | 559 | +----+ | | | | 560 | | | 561 | |-=======================================================-| 562 | | | | 563 | [MN handover] | | | 564 | |---PBU ---->| | | 565 | | |--(5)---PROP_MOD--------->| | 566 | |<--PBA------| [PROP_ID,PROP_TUN] |-tun1 mod->| 567 | | | | | 568 | | +----+ | | | 569 | | |Edge| | | | 570 | | |DPN2| | | | 571 | | +----+ | | | 572 | | | | | | 573 | | |-============================================-| 574 | | | | | 576 Figure 8: Exemplary Message Sequence (focus on FPC reference point) 578 After reception of the Proxy Binding Update (PBU) at the LMA Control- 579 Plane function (LMA_C), the LMA-C selects a suitable DPN, which 580 serves as Data-Plane anchor to the MN's traffic. The LMA-C adds a 581 new logical port to the DPN to treat the MN's traffic (1) and 582 includes a Port Identifier (PRT_ID) to the PRT_ADD command. The 583 LMA-C identifies the selected Anchor DPN by including the associated 584 DPN identifier. 586 Subsequently, the LMA-C adds properties to the new logical port. One 587 property is added (2) to specify the forwarding tunnel type and 588 endpoints (Anchor DPN, Edge DPN1). Another property is added (3) to 589 specify the QoS differentiation, which the MN's traffic should 590 experience. At reception of the properties, the FPC Agent calls 591 local router commands to enforce the tunnel configuration (tun1) as 592 well as the traffic control (tc) for QoS differentiation. After 593 configuration of port properties have been completed, the LMA can 594 configure the enforcement of the MN's traffic by adding a rule 595 (RULE_ADD) to forward traffic destined to the MN's HNP to the new 596 logical port (4). At the reception of the forwarding rule, the Agent 597 applies a new route to forward all traffic destined to the MN's HNP 598 to the configured tunnel interface (tun1). 600 During handover, the LMA-C receives an updating PBU from the handover 601 target MAG-C2. The PBU refers to a new Data-Plane node (Edge DPN2) 602 to represent the new tunnel endpoint. The LMA-C sends a PROP_MOD 603 message (5) to the Agent to modify the existing tunnel property of 604 the existing logical port and to update the tunnel endpoint from Edge 605 DPN1 to Edge DPN2. At reception of the PROP_MOD message, the Agent 606 applies local configuration commands to modify the tunnel. 608 To reduce the number of protocol handshakes between the LMA-C and the 609 DPN, the LMA-C can append property (PROP_TUN, PROP_QOS) and rules 610 (prefix info HNP) attributes to the PRT_ADD message, as illustrated 611 in Figure 9 612 +-----------+ +-------+ +---------+ 613 +------+ +------+ +-----+ FPC | | FPC | | Anchor | 614 |MAG-C1| |MAG-C2| |LMA-C| Client| | Agent | | DPN | 615 +------+ +------+ +-----+-------+ +-------+ +---------+ 616 [MN attach] | | | | 617 |-------------PBU----->| | | 618 | | |----(1)-PRT_ADD----------->| | 619 | | | [PRT_ID,PROP_ID,PROP_TUN, |--tun1 up->| 620 |<------------PBA------| PROP_ID,PROP_QOS, |--tc qos-->| 621 | | | HNP] |-route add>| 622 | [Edge]-=====================================================-| 623 | [DPN1| | | | | 624 | | | | | 625 | [MN handover] | | | 626 | |---PBU ---->| | | 627 | | |---------PROP_MOD--------->| | 628 | |<--PBA------| [PROP_ID,PROP_TUN] |-tun1 mod->| 629 | | | | | 630 | | [Edge]-===========================================-| 631 | | [DPN2] | | | 633 Figure 9: Example: Sequence for Message Aggregation (focus on FPC 634 reference point) 636 5. Conceptual Data Structures 638 An FPC Client must keep record about the logical ports, each port's 639 properties as well as configured rules as per the Mobility Control- 640 Plane function's request. Such information must be maintained for 641 each Agent, with which the Client communicates. In case the Mobility 642 Control-Plane function identifies a particular DPN at which the 643 policies should be enforced, the Client must associate the DPN 644 identifier with the logical port configuration. 646 According to the FPC Agent's role, the Agent translates the 647 generalized model for policy configuration and forwarding rules into 648 semantics and commands for local configuration, which is specific to 649 a DPN. Keeping a local record of DPN configuration attributes/values 650 is implementation specific and out of scope of this document. 652 Description of detailed data structures and information to be 653 recorded and maintained by an FPC Client and an FPC Agent are TBD and 654 will be added to a revision of this initial document. 656 6. Security Considerations 658 Detailed protocol implementations for DMM Forwarding Policy 659 Configuration must ensure integrity of the information exchanged 660 between an FPC Client and an FPC Agent. Required Security 661 Associations may be derived from co-located functions, which utilize 662 the FPC Client and FPC Agent respectively. 664 7. IANA Considerations 666 This document provides an information model for DMM Forwarding Policy 667 Configuration. Detailed protocol specifications for DMM Forwarding 668 Policy Configuration will follow the information model as per this 669 document and can be based on, for example, ReST-like or binary 670 protocol formats. Such protocol-specific details will be described 671 in separate documents and may require IANA actions. 673 8. Work Team Participants 675 Participants in the FPSM work team discussion include Satoru 676 Matsushima, Danny Moses, Sri Gundavelli, Marco Liebsch, Pierrick 677 Seite, Alper Yegin, Carlos Bernardos, Charles Perkins and Fred 678 Templin. 680 9. References 682 9.1. Normative References 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", BCP 14, RFC 2119, March 1997. 687 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 688 "Requirements for Distributed Mobility Management", RFC 689 7333, August 2014. 691 [RFC7429] Liu, D., Zuniga, JC., Seite, P., Chan, H., and CJ. 692 Bernardos, "Distributed Mobility Management: Current 693 Practices and Gap Analysis", RFC 7429, January 2015. 695 9.2. Informative References 697 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 698 August 2002. 700 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 701 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 703 Appendix A. YANG Data Model for the FPC Protocol 705 This appendix provides (so far experimental) formating of some FPC 706 protocol components adopting YANG data modeling. The current FPC 707 information model as per this initial draft version will experience 708 extensions, as it is not yet complete, and may experience changes 709 that need to be reflected in the data model. Whether a detailed data 710 model will be included in this document or solely an information 711 model will be adopted by this document and a detailed data model will 712 be part of a separate document is currently being discussed. 714 module ietf-dmm-fpcp { 715 namespace "urn:ietf:params:xml:ns:yang:dmm-fpcp"; 716 prefix fpcp; 718 import ietf-inet-types { prefix inet; } 720 description 721 "This module contains YANG definition for 722 Forwarding Policy Configuration Protocol.(FPCP)"; 724 revision 2015-03-09 {} 726 typedef fpcp-port-id { 727 description "PRT_ID"; 728 type uint16; 729 } 731 typedef fpcp-property-id { 732 description "PROP_ID"; 733 type uint8; 734 } 736 identity tunnel-type { 737 description 738 "Base identity from which specific use of 739 tunnels are derived."; 740 } 742 identity fpcp-tunnel-type { 743 base "tunnel-type"; 744 description 745 "Base identity from which specific tunnel 746 types in FPCP uses are derived."; 747 } 749 identity ip-in-ip { 750 base "fpcp-tunnel-type"; 751 description "IP-in-IP tunnel"; 752 } 754 identity gtp { 755 base "fpcp-tunnel-type"; 756 description "GTP-U tunnel"; 757 } 759 identity gre { 760 base "fpcp-tunnel-type"; 761 description "GRE tunnel"; 762 } 764 identity ip-protocol { 765 description 766 "Base identity from which specific 767 IP protocol types are derived."; 768 } 770 identity qos-type { 771 description 772 "Base identity from which specific 773 uses of QoS types are derived."; 774 } 776 identity fpcp-qos-type { 777 base "qos-type"; 778 description 779 "Base identity from which specific 780 QoS types in FPCP uses are derived."; 781 } 783 identity fpcp-qos-type-high { 784 base "fpcp-qos-type"; 785 description 786 "An example FPCP QoS Type for high quality class. 787 FPCP supported QoS classes are TBD."; 788 } 790 identity fpcp-qos-type-middle { 791 base "fpcp-qos-type"; 792 description 793 "An example FPCP QoS Type for middle quality class. 794 FPCP supported QoS classes are TBD."; 795 } 797 identity fpcp-qos-type-low { 798 base "fpcp-qos-type"; 799 description 800 "An example FPCP QoS Type for low quality class. 801 FPCP supported QoS classes are TBD."; 802 } 804 grouping fpcp-client { 805 description "CLI_ID to identify FPCP Client"; 806 leaf carrier-id { 807 type uint8; 808 } 809 leaf network-id { 810 type uint8; 811 } 812 leaf client-id { 813 type uint16; 814 mandatory true; 815 } 816 } 818 grouping fpcp-agent { 819 description "AGT_ID to identify FPCP Agent"; 820 leaf carrier-id { 821 type uint8; 822 } 823 leaf network-id { 824 type uint8; 825 } 826 leaf agent-id { 827 type uint16; 828 mandatory true; 829 } 830 } 832 grouping dpn { 833 description "DPN_ID to identify Data-Plane Node"; 834 leaf carrier-id { 835 type uint8; 836 } 837 leaf network-id { 838 type uint8; 839 } 840 leaf dpn-id { 841 type uint16; 842 mandatory true; 843 } 844 } 845 grouping port-property-id { 846 description "PRT_PROP_ID"; 847 leaf port-id { 848 mandatory true; 849 type fpcp-port-id; 850 } 851 leaf property-id { 852 type fpcp-property-id; 853 mandatory true; 854 } 855 } 857 grouping tunnel-endpoints { 858 description 859 "PROP_TUN property as a set of tunnel endpoints"; 860 leaf tunnel-type { 861 type identityref { 862 base "fpcp-tunnel-type"; 863 } 864 } 865 leaf remote-address { 866 type inet:ip-address; 867 } 868 leaf local-address { 869 type inet:ip-address; 870 } 871 } 873 grouping gtp-attributes { 874 description 875 "GTP_CONF as GTP tunnel specific attributes"; 876 leaf remote-teid { 877 type uint32; 878 } 879 leaf local-teid { 880 type uint32; 881 } 882 } 884 grouping gre-attributes { 885 description 886 "GRE_CONF as GRE tunnel specific attribute"; 887 leaf key { 888 type uint32; 889 } 890 } 892 grouping fpcp-identifier-attributes { 893 description 894 "Identifiers of protocol attributes"; 895 leaf port-id { 896 type fpcp-port-id; 897 } 898 container client { 899 uses fpcp-client; 900 } 901 container agent { 902 uses fpcp-agent; 903 } 904 list nodes { 905 key dpn-id; 906 uses dpn; 907 } 908 } 910 grouping fpcp-traffic-descriptor { 911 description 912 "Traffic descriptor group collects parameters to 913 identify target traffic flow and apply QoS policy"; 914 leaf destination-ip { 915 type inet:ip-prefix; 916 } 917 leaf source-ip { 918 type inet:ip-prefix; 919 } 920 leaf protocol { 921 type identityref { 922 base "ip-protocol"; 923 } 924 } 925 leaf destination-port { 926 type inet:port-number; 927 } 928 leaf source-port { 929 type inet:port-number; 930 } 931 leaf qos { 932 type identityref { 933 base "fpcp-qos-type"; 934 } 935 } 936 } 938 grouping fpcp-port-properties { 939 description 940 "A set of port property attributes"; 941 leaf property-id { 942 type fpcp-property-id; 943 } 944 list next-hops { 945 container endpoints { 946 uses tunnel-endpoints; 947 } 948 choice tunnel { 949 case gtp-u { 950 when "tunnel-type = 'gtp'"; 951 uses gtp-attributes; 952 } 953 case gre { 954 when "tunnel-type = 'gre'"; 955 uses gre-attributes; 956 } 957 } 958 } 959 } 961 // Port Entries 963 container port-entries { 964 description 965 "This container binds set of traffic-descriptor and 966 port properties to a port and lists them as a port entry."; 967 list port-entry { 968 key port-id; 969 container identifier { 970 uses fpcp-identifier-attributes; 971 } 972 container trafic-descriptor { 973 uses fpcp-traffic-descriptor; 974 } 975 list properties { 976 uses fpcp-port-properties; 977 } 978 } 979 } 981 // PRT_ADD 983 rpc port_add { 984 description "PRT_ADD"; 985 output { 986 list fpcp-port-entry { 987 uses fpcp-identifier-attributes; 989 } 990 } 991 } 993 // PRT_DEL 995 rpc port_delete { 996 description "PRT_DEL"; 997 input { 998 leaf deleting-port { 999 type fpcp-port-id; 1000 } 1001 } 1002 } 1004 // PROP_ADD 1006 rpc port_property_add { 1007 description "PROP_ADD"; 1008 input { 1009 leaf target-port { 1010 type fpcp-port-id; 1011 mandatory true; 1012 } 1013 container port-properties { 1014 uses fpcp-port-properties; 1015 } 1016 } 1017 } 1019 // PROP_MOD 1021 rpc port_property_modify { 1022 description "PROP_MOD"; 1023 input { 1024 leaf target-port { 1025 type fpcp-port-id; 1026 mandatory true; 1027 } 1028 container port-properties { 1029 uses fpcp-port-properties; 1030 } 1031 } 1032 } 1034 // PROP_DEL 1036 rpc port_property_delete { 1037 description "PROP_DEL"; 1038 input { 1039 container deleting-property { 1040 uses port-property-id; 1041 } 1042 } 1043 } 1045 // RULE_ADD 1047 rpc rule_add { 1048 description 1049 "TBD for input parameters of which RULE_ADD includes 1050 but now just traffic-descriptor."; 1051 input { 1052 leaf target-port { 1053 type fpcp-port-id; 1054 mandatory true; 1055 } 1056 container port-properties { 1057 uses fpcp-traffic-descriptor; 1058 } 1059 } 1060 } 1062 // RULE_MOD 1064 rpc rule_modify { 1065 description 1066 "TBD for input parameters of which RULE_MOD includes 1067 but now just traffic-descriptor."; 1068 input { 1069 leaf target-port { 1070 type fpcp-port-id; 1071 mandatory true; 1072 } 1073 container port-properties { 1074 uses fpcp-traffic-descriptor; 1075 } 1076 } 1077 } 1079 // RULE_DEL 1081 rpc rule_delete { 1082 description 1083 "TBD for input parameters of which RULE_DEL includes 1084 but now just traffic-descriptor."; 1086 input { 1087 leaf target-port { 1088 type fpcp-port-id; 1089 mandatory true; 1090 } 1091 container port-properties { 1092 uses fpcp-traffic-descriptor; 1093 } 1094 } 1095 } 1097 // EVENT_REG 1099 rpc event_register { 1100 description 1101 "TBD for registered parameters included in EVENT_REG."; 1102 } 1104 // PROBE 1106 rpc probe { 1107 description 1108 "TBD for retrieved parameters included in PROBE."; 1109 } 1111 // NOTIFY 1113 notification notify { 1114 description 1115 "TBD for which status and event are reported to client."; 1116 } 1117 } 1119 Figure 10: FPC YANG Data Model 1121 Authors' Addresses 1123 Marco Liebsch 1124 NEC Laboratories Europe 1125 NEC Europe Ltd. 1126 Kurfuersten-Anlage 36 1127 D-69115 Heidelberg 1128 Germany 1130 Phone: +49 6221 4342146 1131 Email: liebsch@neclab.eu 1132 Satoru Matsushima 1133 Softbank Telecom 1134 1-9-1,Higashi-Shimbashi,Minato-Ku 1135 Tokyo 105-7322 1136 Japan 1138 Email: satoru.matsushima@g.softbank.co.jp 1140 Sri Gundavelli 1141 Cisco 1142 170 West Tasman Drive 1143 San Jose, CA 95134 1144 USA 1146 Email: sgundave@cisco.com 1148 Danny Moses 1150 Email: danny.moses@intel.com