idnits 2.17.1 draft-ietf-tsvwg-le-phb-02.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3662, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4594, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC4594, updated by this document, for RFC5378 checks: 2005-02-14) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2017) is 2486 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) ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Bless 3 Internet-Draft Karlsruhe Institute of Technology (KIT) 4 Obsoletes: 3662 (if approved) June 30, 2017 5 Updates: 4594 (if approved) 6 Intended status: Standards Track 7 Expires: January 1, 2018 9 A Lower Effort Per-Hop Behavior (LE PHB) 10 draft-ietf-tsvwg-le-phb-02 12 Abstract 14 This document specifies properties and characteristics of a Lower 15 Effort (LE) per-hop behavior (PHB). The primary objective of this LE 16 PHB is to protect best-effort (BE) traffic (packets forwarded with 17 the default PHB) from LE traffic in congestion situations, i.e., when 18 resources become scarce, best-effort traffic has precedence over LE 19 traffic and may preempt it. There are numerous uses for this PHB, 20 e.g., for background traffic of low precedence, such as bulk data 21 transfers with low priority in time, non time-critical backups, 22 larger software updates, web search engines while gathering 23 information from web servers and so on. This document recommends a 24 standard DSCP value for the LE PHB. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 1, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 74 1.2. Deployment Considerations . . . . . . . . . . . . . . . . 5 75 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 76 2. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 7 78 4. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 7 79 5. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 7 80 6. Changes to RFC 4594 . . . . . . . . . . . . . . . . . . . . . 8 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 85 9.2. Informative References . . . . . . . . . . . . . . . . . 10 86 Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 11 87 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 11 88 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 11 89 Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 12 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 This document defines a Differentiated Services per-hop behavior 95 [RFC2474] called "Lower Effort" (LE) which is intended for traffic of 96 sufficiently low urgency that all other traffic takes precedence over 97 LE traffic in consumption of network link bandwidth. Low urgency 98 traffic has a low priority for timely forwarding, which does not 99 necessarily imply that it is generally of minor importance. From 100 this viewpoint, it can be considered as a network equivalent to a 101 background priority for processes in an operating system. There may 102 or may not be memory (buffer) resources allocated for this type of 103 traffic. 105 Some networks carry traffic for which delivery is considered 106 optional; that is, packets of this type of traffic ought to consume 107 network resources only when no other traffic is present. 108 Alternatively, the effect of this type of traffic on all other 109 network traffic is strictly limited ("no harm" property). This is 110 distinct from "best- effort" (BE) traffic since the network makes no 111 commitment to deliver LE packets. In contrast, BE traffic receives 112 an implied "good faith" commitment of at least some available network 113 resources. This document proposes a Lower Effort Differentiated 114 Services per-hop behavior (LE PHB) for handling this "optional" 115 traffic in a differentiated services node. 117 1.1. Applicability 119 A Lower Effort PHB is applicable for many applications that otherwise 120 use best-effort delivery. More specifically, it is suitable for 121 traffic and services that can tolerate strongly varying throughput 122 for their data flows, especially periods of very low throughput or 123 even starvation (i.e., long interruptions due to significant or even 124 complete packet loss). Therefore, an application sending an LE 125 marked flow must be able to tolerate short or (even very) long 126 interruptions due to the presence of severe congestion conditions 127 during the transmission of the flow. Thus, there should be an 128 expectation that packets of the LE PHB may be excessively delayed or 129 dropped when any other traffic is present. The LE PHB is suitable 130 for sending traffic of low urgency across a Differentiated Services 131 (DS) domain or DS region. 133 LE traffic SHOULD be congestion controlled. Since LE traffic may be 134 starved completely for a longer period of time, transport protocols 135 or applications (and their related congestion control mechanisms) 136 SHOULD be able to detect and react to such a situation and should 137 resume the transfer as soon as possible. Congestion control is not 138 only useful to let the flows within the LE behavior aggregate adapt 139 to the available bandwidth that may be highly fluctuating, but also 140 in case that LE traffic is mapped to the default PHB in DS domains 141 that do not support LE. 143 Use of the LE PHB might assist a network operator in moving certain 144 kinds of traffic or users to off-peak times. Alternatively, or in 145 addition, packets can be designated for the LE PHB when the goal is 146 to protect all other packet traffic from competition with the LE 147 aggregate while not completely banning LE traffic from the network. 148 An LE PHB SHOULD NOT be used for a customer's "normal internet" 149 traffic nor should packets be "downgraded" to the LE PHB instead of 150 being dropped, particularly when the packets are unauthorized 151 traffic. The LE PHB is expected to have applicability in networks 152 that have at least some unused capacity at certain periods. 154 The LE PHB allows networks to protect themselves from selected types 155 of traffic as a complement to giving preferential treatment to other 156 selected traffic aggregates. LE should not be used for the general 157 case of downgraded traffic, but may be used by design, e.g., to 158 protect an internal network from untrusted external traffic sources. 159 In this case there is no way for attackers to preempt internal (non 160 LE) traffic by flooding. Another use case in this regard is 161 forwarding of multicast traffic from untrusted sources. Multicast 162 forwarding is currently enabled within domains only for specific 163 sources within a domain, but not for sources from anywhere in the 164 Internet. A main problem is that multicast routing creates traffic 165 sources at (mostly) unpredictable branching points within a domain, 166 potentially leading to congestion and packet loss. In case multicast 167 packets from untrusted sources are forwarded as LE traffic, they will 168 not harm traffic from non-LE behavior aggregates. A further related 169 use case is mentioned in [RFC3754]: preliminary forwarding of non- 170 admitted multicast traffic. 172 There is no intrinsic reason to limit the applicability of the LE PHB 173 to any particular application or type of traffic. It is intended as 174 an additional traffic engineering tool for network administrators. 175 For instance, it can be used to fill protection capacity of 176 transmission links that is otherwise unused. Some network providers 177 keep link utilization below 50% to ensure that all traffic is 178 forwarded without loss after rerouting caused by a link failure. LE 179 marked traffic can utilize the normally unused capacity and will be 180 preempted automatically in case of link failure when 100% of the link 181 capacity is required for all other traffic. Ideally, applications 182 mark their packets as LE traffic, since they know the urgency of 183 flows. 185 Example uses for the LE PHB: 187 o For traffic caused by world-wide web search engines while they 188 gather information from web servers. 190 o For software updates or dissemination of new releases of operating 191 systems. 193 o For backup traffic or non-time critical synchronization or 194 mirroring traffic. 196 o For content distribution transfers between caches. 198 o For preloading or prefetching objects from web sites. 200 o For Netnews and other "bulk mail" of the Internet. 202 o For "downgraded" traffic from some other PHB when this does not 203 violate the operational objectives of the other PHB or the overall 204 network. 206 o For multicast traffic from untrusted (e.g., non-local) sources. 208 1.2. Deployment Considerations 210 In order to enable LE support, DS nodes typically only need 212 o A BA classifier (Behavior Aggregate classifier, see [RFC2475]) 213 that classifies packets according to the LE DSCP 215 o A dedicated LE queue 217 o A suitable scheduling discipline, e.g., simple priority queueing 219 Alternatively, implementations may use active queue management 220 mechanisms instead of a dedicated LE queue, e.g., dropping all 221 arriving LE packets when certain queue length or sojourn time 222 thresholds are exceeded. 224 Internet-wide deployment of the LE PHB is eased by the following 225 properties: 227 o No harm to other traffic: since the LE PHB has the lowest 228 forwarding priority it does not consume resources from other PHBs. 229 Deployment across different provider domains with LE support 230 causes no trust issues or attack vectors to existing (non LE) 231 traffic. Thus, providers can trust LE markings from end-systems, 232 i.e., there is no need to police or remark incoming LE traffic. 234 o No PHB parameters or configuration of traffic profiles: the LE PHB 235 itself possesses no parameters that need to be set or configured. 236 Similarly, since LE traffic requires no admission or policing, it 237 is not necessary to configure traffic profiles. 239 o No traffic conditioning mechanisms: the LE PHB requires no traffic 240 meters, droppers, or shapers. See also Section 3 for further 241 discussion. 243 DS domains that cannot or do not want to support the LE PHB should be 244 aware that they violate the "no harm" property of LE. DS domains 245 without LE PHB support SHOULD NOT drop LE marked packets, but rather 246 map them to the default PHB and keep the LE DSCP. See also Section 5 247 for further discussion of forwarding LE traffic with the default PHB 248 instead. 250 1.3. Requirements Language 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 254 document are to be interpreted as described in [RFC2119]. 256 2. PHB Description 258 The LE PHB is defined in relation to the default PHB (best-effort). 259 A packet forwarded with the LE PHB SHOULD have lower precedence than 260 packets forwarded with the default PHB, i.e., in case of congestion, 261 LE marked traffic SHOULD be dropped prior to dropping any default PHB 262 traffic. Ideally, LE packets SHOULD be forwarded only if no packet 263 with any other PHB is awaiting transmission. 265 A straightforward implementation could be a simple priority scheduler 266 serving the default PHB queue with higher priority than the lower- 267 effort PHB queue. Alternative implementations may use scheduling 268 algorithms that assign a very small weight to the LE class. This, 269 however, may sometimes cause better service for LE packets compared 270 to BE packets in cases when the BE share is fully utilized and the LE 271 share not. 273 If a dedicated LE queue is not available, an active queue management 274 mechanism within a common BE/LE queue could also be used. This could 275 drop all arriving LE packets as soon as certain queue length or 276 sojourn time thresholds are exceeded. 278 Since congestion control is also useful within the LE traffic class, 279 Explicit Congestion Notification [RFC3168] SHOULD be used for LE 280 packets, too. 282 3. Traffic Conditioning Actions 284 If possible, packets SHOULD be pre-marked in DS-aware end systems by 285 applications due to their specific knowledge about the particular 286 precedence of packets. There is no incentive for DS domains to 287 distrust this initial marking, because letting LE traffic enter a DS 288 domain causes no harm. Thus, any policing such as limiting the rate 289 of LE traffic is not necessary at the DS boundary. 291 As for most other PHBs an initial classification and marking can be 292 also performed at the first DS boundary node according to the DS 293 domain's own policies (e.g., as protection measure against untrusted 294 sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be 295 remarked to LE on a regular basis without consent or knowledge of the 296 user. See also remarks with respect to downgrading in Section 1.1. 298 4. Recommended DS Codepoint 300 The RECOMMENDED codepoint for the LE PHB is '000010'. 302 Earlier specifications [RFC4594] recommended to use CS1 as codepoint 303 (as mentioned in [RFC3662]). This is problematic since it may cause 304 a priority inversion in DiffServ domains that treat CS1 as originally 305 proposed in [RFC2474], resulting in forwarding LE packets with higher 306 precedence than BE packets. Existing implementations SHOULD 307 therefore use the unambiguous LE codepoint '000010' whenever 308 possible. 310 5. Remarking to other DSCPs/PHBs 312 "DSCP bleaching", i.e., setting the DSCP to '000000' (default PHB) is 313 NOT RECOMMENDED for this PHB. This may cause effects that are in 314 contrast to the original intent in protecting BE traffic from LE 315 traffic (no harm property). In case DS domains do not support the LE 316 PHB, they SHOULD treat LE marked packets with the default PHB instead 317 (by mapping the LE DSCP to the default PHB), but they SHOULD do so 318 without remarking to DSCP '000000'. The reason for this is that 319 later traversed DS domains may then have still the possibility to 320 treat such packets according the LE PHB. However, operators of DS 321 domains that forward LE traffic within the BE aggregate should be 322 aware of the implications, i.e., induced congestion situations and 323 quality-of-service degradation of the original BE traffic. In this 324 case, the LE property of not harming other traffic is no longer 325 fulfilled. In order to limit the impact in such cases, traffic 326 policing of the LE aggregate may be used. 328 In case LE marked packets are effectively carried within the default 329 PHB (i.e., forwarded as best-effort traffic) they get a better 330 forwarding treatment than expected. For some applications and 331 services, it is favorable if the transmission is finished earlier 332 than expected. However, in some cases it may be against the original 333 intention of the LE PHB user to strictly send the traffic only if 334 otherwise unused resources are available, i.e., LE traffic may 335 compete with BE traffic for the same resources and thus adversely 336 affect the original BE aggregate. In some cases users want to be 337 sure that their LE marked traffic actually fulfills the "no harm" 338 property. 340 One possible solution for a clear distinction in such cases would be 341 to use two different codepoints, "LE-min = LE, better treatment 342 allowed", "LE-strict = LE, better treatment NOT allowed". However, 343 since DSCPs are a scarce resource, applications that want to ensure 344 the lower precedence compared to BE traffic SHOULD use additionally a 345 corresponding Lower-than-Best-Effort transport protocol [RFC6297], 346 e.g., LEDBAT [RFC6817]. 348 A DS domain that still uses DSCP CS1 for marking LE traffic 349 (including Low Priority-Data as defined in [RFC4594] or the old 350 definition in [RFC3662]) MUST remark traffic to the LE DSCP '000010' 351 at the egress to the next DS domain. This increases the probability 352 that the DSCP is preserved end-to-end, whereas a CS1 marked packet 353 may be remarked by the default DSCP if the next domain is applying 354 DiffServ-intercon [RFC8100]. 356 6. Changes to RFC 4594 358 [RFC4594] recommended to use CS1 as codepoint in section 4.10, 359 whereas CS1 was defined in [RFC2474] to have a higher precedence than 360 CS0, i.e., the default PHB. Consequently, DiffServ domains 361 implementing CS1 according to [RFC2474] will cause a priority 362 inversion for LE packets that contradicts with the original purpose 363 of LE. Therefore, every occurrence of the CS1 DSCP is replaced by 364 the LE DSCP. 366 Changes: 368 o The Low-Priority Data row in Figure 3 is updated as follows: 370 |---------------+---------+-------------+--------------------------| 371 | Low-Priority | LE | 000010 | Any flow that has no BW | 372 | Data | | | assurance | 373 ------------------------------------------------------------------ 375 o The Low-Priority Data row in Figure 4 is updated as follows: 377 |---------------+------+-------------------+---------+--------+----| 378 | Low-Priority | LE | Not applicable | RFCXXXX | Rate | Yes| 379 | Data | | | | | | 380 ------------------------------------------------------------------ 382 o Section 4.10: The RECOMMENDED DSCP marking is LE (Lower Effort). 384 o [RFC4594] recommended to remark Low-Priority Data to DSCP '000001' 385 inside a DS domain that uses IP precedence marking. By using the 386 herein defined LE DSCP such remarking is not necessary, so even if 387 Low-Priority Data is unsupported (i.e., mapped to the default PHB) 388 the LE DSCP should be kept across the domain as RECOMMENDED in 389 Section 5. 391 7. IANA Considerations 393 This document assigns the Differentiated Services Field Codepoint 394 (DSCP) '000010' from the Differentiated Services Field Codepoints 395 (DSCP) registry (https://www.iana.org/assignments/dscp-registry/dscp- 396 registry.xml) to the LE PHB. IANA is requested to update the 397 registry as follows: 399 o Name: LE 401 o Value (Binary): 000010 403 o Value (Decimal): 2 405 o Reference: [RFC number of this memo] 407 8. Security Considerations 409 There are no specific security exposures for this PHB. Since it 410 defines a new class of low forwarding priority, remarking other 411 traffic as LE traffic may lead to quality-of-service degradation of 412 such traffic. Thus, any attacker that is able to modify the DSCP of 413 a packet to LE may carry out a downgrade attack. See the general 414 security considerations in [RFC2474] and [RFC2475]. 416 9. References 418 9.1. Normative References 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 426 "Definition of the Differentiated Services Field (DS 427 Field) in the IPv4 and IPv6 Headers", RFC 2474, 428 DOI 10.17487/RFC2474, December 1998, 429 . 431 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 432 and W. Weiss, "An Architecture for Differentiated 433 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 434 . 436 9.2. Informative References 438 [draft-bless-diffserv-lbe-phb-00] 439 Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop 440 Behavior", draft-bless-diffserv-lbe-phb-00 (work in 441 progress), September 1999, . 444 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 445 of Explicit Congestion Notification (ECN) to IP", 446 RFC 3168, DOI 10.17487/RFC3168, September 2001, 447 . 449 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 450 Per-Domain Behavior (PDB) for Differentiated Services", 451 RFC 3662, DOI 10.17487/RFC3662, December 2003, 452 . 454 [RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated 455 Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754, 456 April 2004, . 458 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 459 Guidelines for DiffServ Service Classes", RFC 4594, 460 DOI 10.17487/RFC4594, August 2006, 461 . 463 [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort 464 Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June 465 2011, . 467 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 468 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 469 DOI 10.17487/RFC6817, December 2012, 470 . 472 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 473 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 474 March 2017, . 476 Appendix A. History of the LE PHB 478 A first version of this PHB was suggested by Roland Bless and Klaus 479 Wehrle in 1999 [draft-bless-diffserv-lbe-phb-00]. After some 480 discussion in the DiffServ Working Group Brian Carpenter and Kathie 481 Nichols proposed a bulk handling per-domain behavior and believed a 482 PHB was not necessary. Eventually, Lower Effort was specified as 483 per-domain behavior and finally became [RFC3662]. More detailed 484 information about its history can be found in Section 10 of 485 [RFC3662]. 487 Appendix B. Acknowledgments 489 Since text is borrowed from earlier Internet-Drafts and RFCs the co- 490 authors of previous specifications are acknowledged here: Kathie 491 Nichols and Klaus Wehrle. David Black and Ruediger Geib provided 492 helpful comments and suggestions. 494 Appendix C. Change History 496 This section briefly lists changes between Internet-Draft versions 497 for convenience. 499 Changes in Version 02: 501 o Applied many editorial suggestions from David Black 503 o Added Multicast traffic use case 505 o Clarified what is required for deployment in section 1.2 506 (Deployment Considerations) 508 o Added text about implementations using AQMs and ECN usage 510 o Updated IANA section according to David Black's suggestions 512 o Revised text in the security section 514 o Changed copyright Notice to pre5378Trust200902 516 Changes in Version 01: 518 o Now obsoletes RFC 3662. 520 o Tried to be more precise in section 1.1 (Applicability) according 521 to R. Geib's suggestions, so rephrased several paragraphs. Added 522 text about congestion control 524 o Change section 2 (PHB Description) according to R. Geib's 525 suggestions. 527 o Added RFC 2119 language to several sentences. 529 o Detailed the description of remarking implications and 530 recommendations in Section 5. 532 o Added Section 6 to explicitly list changes with respect to RFC 533 4594, because this document will update it. 535 Appendix D. Note to RFC Editor 537 This section lists actions for the RFC editor during final 538 formatting. 540 o Please replace the occurrence of RFCXXXX in Section 6 with the 541 assigned RFC number for this document. 543 o Delete Appendix C. 545 o Delete this section. 547 Author's Address 549 Roland Bless 550 Karlsruhe Institute of Technology (KIT) 551 Kaiserstr. 12 552 Karlsruhe 76131 553 Germany 555 Phone: +49 721 608 46413 556 Email: roland.bless@kit.edu