doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc4127.txt b/doc/rfc/rfc4127.txt
new file mode 100644
index 0000000..0fb73fa
--- /dev/null
+++ b/doc/rfc/rfc4127.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                F. Le Faucheur, Ed.
+Request for Comments: 4127                           Cisco Systems, Inc.
+Category: Experimental                                         June 2005
+
+
+            Russian Dolls Bandwidth Constraints Model for
+                Diffserv-aware MPLS Traffic Engineering
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document provides specifications for one Bandwidth Constraints
+   Model for Diffserv-aware MPLS Traffic Engineering, which is referred
+   to as the Russian Dolls Model.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Specification of Requirements ..............................2
+   2. Contributing Authors ............................................3
+   3. Definitions .....................................................4
+   4. Russian Dolls Model Definition ..................................5
+   5. Example Formulas for Computing "Unreserved TE-Class [i]" with
+      Russian Dolls Model .............................................7
+   6. Receiving Both Maximum Reservable Bandwidth and Bandwidth
+      Constraints sub-TLVs ............................................8
+   7. Security Considerations .........................................8
+   8. IANA Considerations .............................................8
+   9. Acknowledgements ................................................9
+   Appendix A: Addressing [DSTE-REQ] Scenarios .......................10
+   Normative References ..............................................11
+   Informative References ............................................12
+
+
+
+
+
+
+
+
+
+Le Faucheur                   Experimental                      [Page 1]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+1.  Introduction
+
+   [DSTE-REQ] presents the Service Providers requirements for support of
+   Diffserv-aware MPLS Traffic Engineering (DS-TE).  This includes the
+   fundamental requirement to be able to enforce different Bandwidth
+   Constraints for different classes of traffic.
+
+   [DSTE-REQ] also defines the concept of Bandwidth Constraints Model
+   for DS-TE and states that "The DS-TE technical solution MUST specify
+   at least one Bandwidth Constraints Model and MAY specify multiple
+   Bandwidth Constraints Models".
+
+   This document provides a detailed description of one particular
+   Bandwidth Constraints Model for DS-TE which is introduced in
+   [DSTE-REQ] and called the Russian Dolls Model (RDM).
+
+   [DSTE-PROTO] specifies the Interior Gateway Protocol (IGP) and RSVP-
+   TE signaling extensions for support of DS-TE.  These extensions
+   support RDM.
+
+1.1.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur                   Experimental                      [Page 2]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+2.  Contributing Authors
+
+   This document was the collective work of several authors.  The text
+   and content were contributed by the editor and the co-authors listed
+   below. (The contact information for the editor appears in the
+   Editor's Address section.)
+
+   Jim Boyle                               Kireeti Kompella
+   Protocol Driven Networks, Inc.          Juniper Networks, Inc.
+   1381 Kildaire Farm Road #288            1194 N. Mathilda Ave.
+   Cary, NC 27511, USA                     Sunnyvale, CA 94099
+
+   Phone: (919) 852-5160                   EMail: kireeti@juniper.net
+   EMail: jboyle@pdnets.com
+
+
+   William Townsend                        Thomas D. Nadeau
+   Tenor Networks                          Cisco Systems, Inc.
+   100 Nagog Park                          250 Apollo Drive
+   Acton, MA 01720                         Chelmsford, MA 01824
+
+   Phone: +1-978-264-4900                  Phone: +1-978-244-3051
+   EMail: btownsend@tenornetworks.com      EMail: tnadeau@cisco.com
+
+
+   Darek Skalecki
+   Nortel Networks
+   3500 Carling Ave,
+   Nepean K2H 8E9
+
+   Phone: +1-613-765-2252
+   EMail: dareks@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur                   Experimental                      [Page 3]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+3.  Definitions
+
+   For readability a number of definitions from [DSTE-REQ] are repeated
+   here:
+
+   Class-Type (CT): the set of Traffic Trunks crossing a link that is
+                    governed by a specific set of bandwidth constraints.
+                    CT is used for the purposes of link bandwidth
+                    allocation, constraint-based routing and admission
+                    control.  A given Traffic Trunk belongs to the same
+                    CT on all links.
+
+   TE-Class:        A pair of:
+
+                    i.  a Class-Type
+
+                    ii. a preemption priority allowed for that Class-
+                    Type.  This means that an LSP transporting a Traffic
+                    Trunk from that Class-Type can use that preemption
+                    priority as the setup priority, the holding
+                    priority, or both.
+
+   A number of recovery mechanisms under investigation or specification
+   in the IETF take advantage of the concept of bandwidth sharing across
+   particular sets of LSPs.  "Shared Mesh Restoration" in [GMPLS-RECOV]
+   and "Facility-based Computation Model" in [MPLS-BACKUP] are example
+   mechanisms that increase bandwidth efficiency by sharing bandwidth
+   across backup LSPs protecting against independent failures.  To
+   ensure that the notion of "Reserved (CTc)" introduced in [DSTE-REQ]
+   is compatible with such a concept of bandwidth sharing across
+   multiple LSPs, the wording of the "Reserved (CTc)" definition
+   provided in [DSTE-REQ] is generalized into the following:
+
+   Reserved (CTc):  For a given Class-Type CTc ( 0 <= c <= MaxCT ), let
+                    us define "Reserved(CTc)" as the total amount of the
+                    bandwidth reserved by all the established LSPs which
+                    belong to CTc.
+
+   With this generalization, the Russian Dolls Model definition provided
+   in this document is compatible with Shared Mesh Restoration defined
+   in [GMPLS-RECOV], so that DS-TE and Shared Mesh Protection can
+   operate simultaneously.  This assumes that Shared Mesh Restoration
+   operates independently within each DS-TE Class-Type and does not
+   operate across Class-Types (for example, backup LSPs protecting
+   Primary LSPs of CTx also need to belong to CTx; Excess Traffic LSPs
+   sharing bandwidth with Backup LSPs of CTx also need to belong to
+   CTx).
+
+
+
+
+Le Faucheur                   Experimental                      [Page 4]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+   We also introduce the following definition:
+
+   Reserved(CTb,q): Let us define "Reserved(CTb,q)" as the total amount
+                    of the bandwidth reserved by all the established
+                    LSPs that belong to CTb and have a holding priority
+                    of q.  Note that if q and CTb do not form one of the
+                    8 possible configured TE-Classes, then there cannot
+                    be any established LSPs that belongs to CTb and has
+                    a holding priority of q; therefore, in this case,
+                    Reserved(CTb,q) = 0.
+
+4.  Russian Dolls Model Definition
+
+   RDM is defined in the following manner:
+
+        o Maximum Number of Bandwidth Constraints (MaxBC)=
+             Maximum Number of Class-Types (MaxCT) = 8
+
+        o for each value of b in the range 0 <= b <= (MaxCT - 1):
+             SUM (Reserved (CTc)) <= BCb,
+             where the SUM is across all values of c in the
+             range b <= c <= (MaxCT - 1)
+
+        o BC0= Maximum Reservable Bandwidth, so that
+             SUM (Reserved(CTc)) <= Max-Reservable-Bw,
+             where the SUM is across all values of c in the
+             range  0 <= c <= (MaxCT - 1)
+
+   A DS-TE LSR implementing RDM MUST support enforcement of Bandwidth
+   Constraints in compliance with this definition.
+
+   Both preemption within a CT and across CTs is allowed.
+
+   Where 8 CTs are active, the RDM Bandwidth Constraints can also be
+   expressed in the following way:
+
+      - All LSPs from CT7 use no more than BC7
+
+      - All LSPs from CT6 and CT7 use no more than BC6
+
+      - All LSPs from CT5, CT6 and CT7 use no more than BC5
+
+      - etc.
+
+      - All LSPs from CT0, CT1, ..., CT7 use no more than BC0 = "Maximum
+        Reservable Bandwidth"
+
+
+
+
+
+Le Faucheur                   Experimental                      [Page 5]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+   Purely for illustration purposes, the diagram below represents the
+   Russian Dolls Bandwidth Constraints Model in a pictorial manner when
+   3 Class-Types are active:
+
+   I------------------------------------------------------I
+   I-------------------------------I                      I
+   I--------------I                I                      I
+   I    CT2       I    CT2+CT1     I      CT2+CT1+CT0     I
+   I--------------I                I                      I
+   I-------------------------------I                      I
+   I------------------------------------------------------I
+
+   I-----BC2------>
+   I----------------------BC1------>
+   I------------------------------BC0=Max Reservable Bw--->
+
+   While simpler Bandwidth Constraints models or, conversely, more
+   flexible/sophisticated Bandwidth Constraints models can be defined,
+   the Russian Dolls Model is attractive in some DS-TE environments for
+   the following reasons:
+
+      - Although it is a little less intuitive than the Maximum
+        Allocation Model (see [DSTE-MAM]), RDM is still a simple model
+        to conceptualize.
+
+      - RDM can be used simultaneously to ensure bandwidth efficiency
+        and to protect against QoS degradation of all CTs, whether
+        preemption is used or not.
+
+      - RDM can be used in conjunction with preemption to simultaneously
+        achieve (i) isolation across CTs (so that each CT is guaranteed
+        its share of bandwidth no matter the level of contention by
+        other classes), (ii) bandwidth efficiency, and (iii) protection
+        against QoS degradation of all CTs.
+
+      - RDM only requires limited protocol extensions such as the ones
+        defined in [DSTE-PROTO].
+
+   RDM may not be attractive in some DS-TE environments for the
+   following reasons:
+
+      - if the usage of preemption is precluded for some administrative
+        reason, while RDM can still ensure bandwidth efficiency and
+        protection against QoS degradation of all CTs, RDM cannot
+        guarantee isolation across Class-Types.
+
+   Additional considerations on the properties of RDM can be found in
+   [BC-CONS] and [BC-MODEL].
+
+
+
+Le Faucheur                   Experimental                      [Page 6]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+   As a simple example usage of the "Russian Dolls" Bandwidth
+   Constraints Model, a network administrator, using one CT for Voice
+   (CT1) and one CT for data (CT0), might configure on a given link:
+
+      - BC0 = Max-Reservable - Bw = 2.5 Gb/s (i.e., Voice + Data is
+        limited to 2.5 Gb/s)
+
+      - BC1 = 1.5 Gb/s (i.e., Voice is limited to 1.5 Gb/s).
+
+5.  Example Formulas for Computing "Unreserved TE-Class [i]" with
+    Russian Dolls Model
+
+   As specified in [DSTE-PROTO], formulas for computing "Unreserved TE-
+   Class [i]" MUST reflect all of the Bandwidth Constraints relevant to
+   the CT associated with TE-Class[i], and thus, depend on the Bandwidth
+   Constraints Model.  Thus, a DS-TE LSR implementing RDM MUST reflect
+   the RDM Bandwidth Constraints defined in section 4 above when
+   computing "Unreserved TE-Class [i]".
+
+   As explained in [DSTE-PROTO], the details of admission control
+   algorithms, as well as formulas for computing "Unreserved TE-Class
+   [i]", are outside the scope of the IETF work.  Keeping that in mind,
+   we provide in this section an example for illustration purposes, of
+   how values for the unreserved bandwidth for TE-Class[i] might be
+   computed with RDM.  In the example, we assume the basic admission
+   control algorithm, which simply deducts the exact bandwidth of any
+   established LSP from all of the Bandwidth Constraints relevant to the
+   CT associated with that LSP.
+
+   We assume that:
+
+        TE-Class [i] <--> < CTc , preemption p>
+
+   in the configured TE-Class mapping.
+
+   For readability, formulas are first shown assuming only 3 CTs are
+   active.  The formulas are then extended to cover the cases where more
+   CTs are used.
+
+   If CTc = CT0, then "Unreserved TE-Class [i]" =
+      [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
+
+   If CTc = CT1, then "Unreserved TE-Class [i]" =
+      MIN  [
+      [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2,
+      [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
+             ]
+
+
+
+
+Le Faucheur                   Experimental                      [Page 7]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+   If CTc = CT2, then "Unreserved TE-Class [i]" =
+      MIN  [
+      [ BC2 - SUM ( Reserved(CTb,q) ) ] for q <= p and 2 <= b <= 2,
+      [ BC1 - SUM ( Reserved(CTb,q) ) ] for q <= p and 1 <= b <= 2,
+      [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 2
+             ]
+
+   The formula can be generalized to 8 active CTs and expressed in a
+   more compact way in the following:
+
+     "Unreserved TE-Class [i]" =
+      MIN  [
+    [ BCc - SUM ( Reserved(CTb,q) ) ] for q <= p and c <= b <= 7,
+    [ BC(c-1) - SUM ( Reserved(CTb,q) ) ] for q <= p and (c-1)<= b <= 7,
+        . . .
+    [ BC0 - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7,
+           ]
+
+      where:
+
+        TE-Class [i] <--> < CTc , preemption p>
+        in the configured TE-Class mapping.
+
+6.  Receiving Both Maximum Reservable Bandwidth and Bandwidth
+    Constraints sub-TLVs
+
+   [DSTE-PROTO] states that "A DS-TE LSR, which does advertise BCs, MUST
+   use the new "Bandwidth Constraints" sub-TLV (in addition to the
+   existing Maximum Reservable Bandwidth sub-TLV) to do so."
+
+   With RDM, BC0 is equal to the Maximum Reservable Bandwidth because
+   they both represent the aggregate constraint across all CTs.  Thus, a
+   DS-TE LSR, receiving both the "Maximum Reservable Bw" sub-TLV and the
+   new "Bandwidth Constraints" sub-TLV (which contains BC0) for a given
+   link where the RDM model is used, MAY ignore the "Maximum Reservable
+   Bw" sub-TLV.
+
+7.  Security Considerations
+
+   Security considerations related to the use of DS-TE are discussed in
+   [DSTE-PROTO].  Those apply independently of the Bandwidth Constraints
+   Model, including RDM specified in this document.
+
+8.  IANA Considerations
+
+   [DSTE-PROTO] defines a new name space for "Bandwidth Constraints
+   Model Id".  The guidelines for allocation of values in that name
+   space are detailed in section 13.1 of [DSTE-PROTO].  In accordance
+
+
+
+Le Faucheur                   Experimental                      [Page 8]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+   with these guidelines, the IANA has assigned a Bandwidth Constraints
+   Model Id for RDM from the range 0-239 (which is to be managed as per
+   the "Specification Required" policy defined in [IANA-CONS]).
+
+   Bandwidth Constraints Model Id 0 was allocated by IANA to RDM.
+
+9.  Acknowledgements
+
+   We thank Martin Tatham for his key contribution in this work.
+   Tatiana Renko is also warmly thanked for her instantiation of the
+   Russian Doll.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Faucheur                   Experimental                      [Page 9]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+Appendix A: Addressing [DSTE-REQ] Scenarios
+
+   This appendix provides examples of how the Russian Dolls Bandwidth
+   Constraints Model can be used to support each of the scenarios
+   described in [DSTE-REQ].
+
+A.1.  Scenario 1: Limiting Amount of Voice
+
+   By configuring on every link:
+
+      - Bandwidth Constraint 1 (for CT1 = Voice) = "certain percentage"
+        of link capacity
+
+      - BC0 (for CT1=Voice + CT0=Data) = link capacity
+
+   By configuring:
+
+      - every CT1/Voice TE-LSP with preemption = 0
+
+      - every CT0/Data TE-LSP with preemption = 1
+
+   DS-TE with the Russian Dolls Model will address all the requirements:
+
+      - amount of Voice traffic limited to desired percentage on every
+        link
+
+      - data traffic capable of using all remaining link capacity
+
+      - voice traffic capable of preempting other traffic
+
+A.2.  Scenario 2: Maintain Relative Proportion of Traffic Classes
+
+   By configuring on every link:
+
+      - BC2 (for CT2) = e.g., 45%
+
+      - BC1 (for CT1+CT2) = e.g., 80%
+
+      - BC0 (for CT0+CT1+CT2) = e.g., 100%
+
+   DS-TE with the RDM will ensure that the amount of traffic of each CT
+   established on a link is within acceptable levels as compared to the
+   resources allocated to the corresponding Diffserv Per Hop Behaviors
+   (PHBs) regardless of which order the LSPs are routed in, regardless
+   of which preemption priorities are used by which LSPs and regardless
+   of failure situations.
+
+
+
+
+
+Le Faucheur                   Experimental                     [Page 10]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+   By also configuring:
+
+      - every CT2/Voice TE-LSP with preemption = 0
+
+      - every CT1/Premium Data TE-LSP with preemption = 1
+
+      - every CT0/Best-Effort TE-LSP with preemption = 2
+
+   DS-TE with the Russian Dolls Model will also ensure that:
+
+      - CT2 Voice LSPs always have first preemption priority in order to
+        use the CT2 capacity
+
+      - CT1 Premium Data LSPs always have second preemption priority in
+        order to use the CT1 capacity
+
+      - Best-Effort can use up to link capacity of what is left by CT2
+        and CT1.
+
+   Optional automatic adjustment of Diffserv scheduling configuration
+   could be used for maintaining very strict relationships between the
+   amounts of established traffic of each Class Type and corresponding
+   Diffserv resources.
+
+A.3.  Scenario 3: Guaranteed Bandwidth Services
+
+   By configuring on every link:
+
+      - BC1 (for CT1) = "given" percentage of link bandwidth
+        (appropriate to achieve the Guaranteed Bandwidth service's QoS
+        objectives)
+
+      - BC0 (for CT0+CT1) = 100% of link bandwidth
+
+   DS-TE with the Russian Dolls Model will ensure that the amount of
+   Guaranteed Bandwidth Traffic established on every link remains below
+   the given percentage so that it will always meet its QoS objectives.
+   At the same time, it will allow traffic engineering of the rest of
+   the traffic such that links can be filled up.
+
+Normative References
+
+   [DSTE-REQ]    Le Faucheur, F. and W. Lai, "Requirements for Support
+                 of Differentiated Services-aware MPLS Traffic
+                 Engineering", RFC 3564, July 2003.
+
+
+
+
+
+
+Le Faucheur                   Experimental                     [Page 11]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+   [DSTE-PROTO]  Le Faucheur, F., Ed., "Protocol Extensions for Support
+                 of Diffserv-aware MPLS Traffic Engineering", RFC 4124,
+                 June 2005.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [IANA-CONS]   Narten, T. and H. Alvestrand, "Guidelines for Writing
+                 an IANA Considerations Section in RFCs", BCP 26, RFC
+                 2434, October 1998.
+
+Informative References
+
+   [BC-CONS]     Le Faucheur, F., "Considerations on Bandwidth
+                 Constraints Model for DS-TE", Work in Progress, June
+                 2002.
+
+   [BC-MODEL]    Lai, W., "Bandwidth Constraints Models for
+                 Differentiated Services (Diffserv)-aware MPLS Traffic
+                 Engineering:  Performance Evaluation", RFC 4128, June
+                 2005.
+
+   [DSTE-MAM]    Le Faucheur, F. and W. Lai, "Maximum Allocation
+                 Bandwidth Constraints Model for Diffserv-aware MPLS
+                 Traffic Engineering", RFC 4125, June 2005.
+
+   [GMPLS-RECOV] Lang, et al., "Generalized MPLS Recovery Functional
+                 Specification", Work in Progress.
+
+   [MPLS-BACKUP] Vasseur, et al., "MPLS Traffic Engineering Fast
+                 Reroute:  Bypass Tunnel Path Computation for Bandwidth
+                 Protection", Work in Progress.
+
+Editor's Address
+
+   Francois Le Faucheur
+   Cisco Systems, Inc.
+   Village d'Entreprise Green Side - Batiment T3
+   400, Avenue de Roumanille
+   06410 Biot-Sophia Antipolis
+   France
+
+   Phone: +33 4 97 23 26 19
+   EMail: flefauch@cisco.com
+
+
+
+
+
+
+
+Le Faucheur                   Experimental                     [Page 12]
+
+RFC 4127             Russian Dolls Model for DS-TE             June 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Le Faucheur                   Experimental                     [Page 13]
+