[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

INTERNET DRAFT                             E.Muramoto,Y.Imai,N.Kawaguchi
<draft-muramoto-irtf-sam-generic-require-01.txt>            WIDE project
                                                          November, 2006
                                                      Expires June, 2007

         Requirements for Scalable Adaptive Multicast Framework
                          in Non-GIG Networks

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [2119].
   Allocation policy names Specification Required, IETF Consensus
   Action, and Designated Expert are to be interpreted as described in
   RFC 2434 [2434]

Copyright Notice

      Copyright (C) The Internet Society (2006).


   The Scalable Adaptive Multicast (SAM) Research Group is chartered to
   explore and research techniques which improve multicast performance
   with respect to dimensions such as number of groups, dynamics of
   group membership, dynamics of the network topology, and network

Eiichi, et al.              Expires June 2007                   [Page 1]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006

   resource constraints.  This document describes requirements for SAM
   framework, especially for non-GIG environment.

Table of Contents

   1. Introduction
   2. What is SAM
   3. non-GIG requirement for SAM framework
   3.1 Multicast capability
   3.2 Minimizing the infrastructure support and fastening the service-connectivity cycle
   3.3 Scalability problems
   3.3.1 Routing convergence
   3.3.2 Dynamic topology
   3.3.3 Number of group
   3.3.4 Dynamics of group membership
   3.4 Adaptivity for real-time communication
   3.4.1 Latency (Delay sensitivity)
   3.4.2 Data rate control & Congestion avoidance
   3.4.3 Redundancy path
   3.5 Capability for non stream application
   3.5.1 Interactive application
   3.5.2 File transfer
   4 Interoperability of existing method
   4.1 ALM
   4.2 OM
   4.3 Selfish routing
   4.4 Native IP multicast
   4.5 Cooperation with Network TE in overlay approach
   4.6 eXplicit Multi-Unicast (Xcast)
   4.7 Brief consideration on harmonization
   4.7.1 One does not fit all
   4.7.2 Assumed requirement for harmonization
   5. Security consideration
   5.1 Unexpected utilization of resources
   5.2 Authorization of group membership
   5.3 Mechanism to limit denial of service attack
   5.4 Encryption and key distribution
   6. Informative Reference
   7. Author's Addresses
   8. Full Copyright Statement
   9. IPR Notices


    Changes from draft-muramoto-irtf-sam-generic-require-00.txt:

    * Added a discussion on harmonization (4.7) inspired by the e-mail
   by Jun Lei and Yuji Imai.

Eiichi, et al.              Expires June 2007                   [Page 2]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006

    * Changed the name of paragraph to Minimizing the infrastructure
   support and fastening the service-connectivity cycle (3.2) inspired
   by the e-mail by Jun Lei and Yuji Imai.

    * Added a few sentences of latencies (3.4.1) based on the e-mail
   from Rick Boivie

    * Changed the name of paragraph to Number of group (3.3.3) and added
   a few sentences based on the e-mail from Rick Boivie

    * Added a few sentences of fast routing convergence (3.3.1) based on
   the e-mail from Rick Boivie

    ->00: - initial submission

1. Introduction

   IP Multicast[1112][1075][2236][CHER][DEER][DEE2][MBONE] has achieved
   great engineering success. Various protocols, SSM[3569], PIM[2362],
   MSDP[FARI] and MBGP[2858]  will provide firm basements for
   distribution of live contents like TV programs broadcasting all over
   the Internet. And bulk content delivery could be achieved by
   standardized RMT protocols [RMT].

   On the other hand, it is possible to improve multicast performance
   with respect to dimensions such as number of groups, dynamics of
   group membership, dynamics of the network topology, and network
   resource constraints.  Alternative technologies such as end-system
   multicast [ESM], [YOID], [NICE], [ALMI], [TAG], [DTO], [CAN],
   [BAYEUX], [XCID] and overlay multicast[SCX], [OVERCAST], [RMX],
   [MSN], [OMNI], [AKAMAI], [IBEAM] have been demonstrated to achieve
   such improvement. But these mechanisms have not been integrated into
   a unified architecture and operational design.

   SAM (Scalable Adaptive Multicast) research group[SAM] is chartered to
   explore and research such techniques. This document describes
   requirements for SAM framework, especially for non-GIG environment.

2. What is SAM

   The Scalable Adaptive Multicast (SAM) Research Group is chartered to
   explore and research techniques which improve multicast performance
   with respect to dimensions such as number of groups, dynamics of
   group membership, dynamics of the network topology, and network
   resource constraints. The RG will investigate approaches based on
   application layer multicast (ALM), overlay multicast (OM), and native
   IP multicast, as well as hybrid approaches. A key design
   consideration is the placement of multicast state information along

Eiichi, et al.              Expires June 2007                   [Page 3]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006

   the multicast path, including packet headers, end hosts, and network
   nodes, where placement may be determined adaptively.

3. non-GIG requirement for SAM framework

   The Global Information Grid (GIG)[GIG] is a large and complex
   undertaking that is intended to integrate virtually all of the
   information systems, services, and applications in the US Department
   of Defense (DoD) into one seamless, re-liable, and secure network.

   But in this document, we enumerate requirement for SAM framework
   which is NOT specific to GIG.

   This section describes the non-GIG requirements.

3.1 Multicast capability

   SAM framework must support point to multipoint communication and may
   support multipoint to multipoint communication. Native IP multicast
   can support one to many bulk data transfer and broadcasting. SAM
   framework provides compliment  and integrated method of one to many
   and many to many communication.

3.2 Minimizing the infrastructure support and fastening the service-
   connectivity cycle

   To start up a networking, it is quite important to minimize the
   change to existing network infrastructure [MOSSDAV]. Native IP
   multicast requires infrastructure support and it sometimes cause
   difficulty to evolve because initial proposals always looks very
   ambitions and it is very hard for multiple organizations (i.e.
   carriers, ISPs) to negotiate and to agree to deploy something at the
   same time.  User initiate start up function and incremental
   deployment function is quite important for SAM-RG to design the SAM

3.3 Scalability problems

   SAM framework should support various scalabilities. This section
   enumerates the scalability problems.

3.3.1 Fast routing convergence

   Multicast distribution tree must be maintained even if the unicast
   routing path is changed. The convergence period should be short. This
   requirement is common among Native IP multicast, ALM, OM and the
   future hybrid SAM solutions.  The SAM framework should be able to
   rapidly adapt to changes in network topology  even if there is a

Eiichi, et al.              Expires June 2007                   [Page 4]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006

   large number of multicast groups, even if group membership is highly
   dynamic and even if lots of group members are moving.  To state this
   requirement in a more quantifiable way, multicast routing should
   converge for 95% of the affected groups within 1 second, say, after
   convergence of unicast routing (to minimize outages of VoIP
   conference, e-meetings etc.)

3.3.2 Dynamic topology change

   Multicast forwarding functions (i.e. router or receiver) are not
   always settled in fixed locations. Mobile [NEMO] and MANET [MANET]
   situation might be assumed.  In such a situation, the router location
   and link topology are dynamically changed. Multicast distribution
   tree must be maintained in such case too.

3.3.3 Number of group

   The number of group all over the Internet would be quite large. We
   should assume millions of human group communication and multiple
   sensors(i.e. machine to machine) networks all over the world.  That
   is, the SAM framework should be scalable in that it should be able to
   support a very large number of multicast groups (since the network
   will need to support very large numbers of groups for VoIP conference
   calls, for videoconferences, e-meetings and other applications).

3.3.4 Dynamic management of group membership

   Many communications would be generated at the same time all over the
   world. And it is necessary to assume frequent change of group
   membership for the management mechanism.

3.4 Adaptivity for real-time communication

   In the real-time group communication over the best effort network,
   adaptation mechanism is necessary. This section describes describe
   the requirement for real-time group communication.

3.4.1 Latency (Delay sensitivity)

   The end to end delay of the conversation over the network should be
   shorten. The delivery path of the multipoint communication should be
   optimized to shorten the total transmission delay.

   Multicast packets should follow "close to optimal" routes from a
   source to a destination.  To state this in a more quantifiable and
   measurable way, the end-to-end delay from a source, s, to a
   destination, d, in a multicast transmission should be no more than 50
   msec (say) longer than the end-to-end delay of a unicast transmission

Eiichi, et al.              Expires June 2007                   [Page 5]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006

   from s to d. (Need to have good end-to-end delay to support full-
   duplex, real-time VoIP communications.)

   Multicast should not artificially concentrate traffic on certain
   nodes or certain links (think rendez-vous points) since this can
   introduce unnecessary queuing delays and unnecessary packet loss in
   addition to unnecessarily long network paths and unnecessarily large
   end-to-end latencies.

3.4.2 Data rate control & Congestion avoidance

   In SAM framework, overlay such approach as ALM or OM might be taken.
   in such a situation, multiple delivery path might share a physical
   network link. The mechanisms to fairly share the bandwidth and to
   avoid congestion would be necessary.

3.4.3 Redundancy path

   In SAM framework, the receiver might take a part of forwarder. The
   membership of the forwarding path might be unexpectedly changed
   without relationship to the membership of real-time group
   communication. The management mechanism should take care about such

3.5 Capability for non streaming application

   There exist strong requirement of the collaboration over the
   Internet.  This section enumerates requirement for non streaming

3.5.1 Interactive application

   Internet game and collaboration tools like white board or remote
   presentation are the representatives of interactive applications.
   Such application might exchanges bursty or intermittent traffic
   between participants. Both of latency and reliability might be the
   most important for those applications.

3.5.2 File transfer

   Sharing file between participants are required in multipoint group
   communications. Casual file sharing like instant message should be
   achieved easily in SAM framework.

3.5.3 Data collection

   Data collection from remote sensor is required. Bi-directional
   distribution tree in SAM framework might be used for such purpose.

Eiichi, et al.              Expires June 2007                   [Page 6]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006

4 Interoperability of existing methods

   Application layer multicast (ALM), overlay multicast (OM), and native
   IP multicast are separately developed. Harmonizing of those
   technologies might be one of the requirements for SAM framework. This
   section explains each technology and harmonization briefly.

4.1 ALM

   Application layer multicast generates distribution tree between
   terminals. Logical group management function or the joining algorithm
   automatically calculates optimal path for all participations.

4.2 OM

   Overlay multicast connects each individual multicast enable network
   by unicast tunneling. Addressing space of multicast group can be
   maintained by transform function. As ALM, logical group management
   function calculates optimal path between networks.

4.3 Selfish routing

   Many research points out problems of selfish routing in overlay
   approach [TAON], [SROU], [CMP], [ITOL], [PAA], [EEA]. The logical
   group management function optimize their own performance goals not
   considering system-wide criteria. It means traffic cannot be
   controlled by the network operator.

4.4 Native IP multicast

   Native IP multicast manages receivers in the distributed method. Edge
   router aggregates tree construction request and routing algorithm
   finds source and generates distribution tree between edge routers.
   Trees are constructed from leaf (i.e. edge router) to root (i.e. the
   source) based on the unicast routing information. Network operator
   can imagine the tree construction and control it. It means trees and
   traffic can be managed by the network operator.

4.5 Cooperation with Network TE in overlay approach

   Network traffic could be controlled by the network operator to keep
   network healthy and grown up effectively. Overlay approaches have
   problem about selfish routing and bandwidth consuming. But SAM
   framework should provide the chance to traffic engineering while
   forming distribution tree or transmitting real-time streaming.

4.6 eXplicit Multi-Unicast (Xcast)

Eiichi, et al.              Expires June 2007                   [Page 7]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006

   eXplicit Multi-Unicast (Xcast) is a new multicast scheme with
   complementary scaling properties: Xcast supports a very large number
   of small multicast sessions.  Xcast achieves this by explicitly
   encoding the list of destinations in the data packets, instead of
   using a multicast group address. Therefore, the data packets has
   knowledge about distribution tree. It might mean Xcast packet could
   give the network operator the chance to estimate the traffic trend
   and to increase the bandwidth properly.

4.7 Brief consideration on harmonization

4.7.1 One does not fit all

   The requirements that has been described above includes many things.
   It is difficult to fill everything with one mechanism. An above-
   mentioned individual mechanism doesn't meet all demands at the same
   time either. Those are not mandatory rather than we have to choose
   subset of them depends on real-applications we would use.

4.7.2 Assumed requirement for harmonization

   A part of mechanism requires a fixed-point (e.g. a rendezvous point
   or a group management function) on the Internet, and a part of
   mechanism needs the router support or the relay servers when
   forwarding packets. They try to deploy their own mechanism
   independently. We can assume that a specific network service operator
   introduce the specific fixed point, the router support, or the relay
   servers for specific service which they want to introduce (e.g. for
   video conferencing, a group management for XCAST, and for TV
   broadcasting, relay servers for an OM).  The SAM framework might have
   to include the interconnectivity of such state-of-the-art methods.

5. Security consideration
5.1 Unexpected utilization of resources

   Some overlay approach try to use the unused resource on the Internet.
   They try to make efficient and robust path using other person's
   resources. But in real time communication, resource might be used
   heavily and continuously. It sometimes suffer the resource owner
   unexpectedly.  Unexpected resource use could be avoided in SAM

5.2 Authorization of group membership

   Native IP multicast aggregates receiver join request at the edge
   router and the edge router need not manage individual receiver in
   normal case. It provides receiver initiated multipoint communication.
   But it also give the chance to malicious receiver to be a black hole

Eiichi, et al.              Expires June 2007                   [Page 8]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006

   sink for all multicast group.  Authorization of group membership
   should be supported in SAM framework.

5.3 Mechanism to limit denial of service attack

   Multi-point overlay approach essentially has the function to
   duplicate packet and forward to multipoint. The mechanism to limit
   denial of service attack should be thought while designing SAM

5.4 Encryption and key distribution

   It should be possible for a source to protect streaming content from
   viewing by intermediate nodes that are not part of the group.  Point
   to multipoint association and key distribution mechanism should be
   carefully designed.

15. Informative References

[1112]  S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
        August 1989.

[1075]  D. Waitzman, C. Partridge, S.E. Deering, Distance Vector Multi-
        cast Routing Protocol, RFC 1075, November 1988.

[2236]  W. Fenner, Internet Group Management Protocol, Version 2, RFC
        2236, Nov. 1997.

[CHER]  David R. Cheriton , Stephen E. Deering, Host groups: a multicast
        extension for datagram internetworks, Proceedings of the ninth
        symposium on Data communications, p.172-179, September 1985,
        Whistler Moutain, British Columbia, Canada

[DEER]  S. Deering, "Multicast Routing in a datagram internetwork", PhD
        thesis, December 1991.

[DEE2]  S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L.
        Wei. The Pim Architecture for Wide-area Multicast Routing, ACM
        Transactions on Networks, April 1996

[FARI]  D. Farinacci, "Multicast Source Discovery Protocol", draft-fari-
        nacci-msdp-00.txt, June 1998.

[3569]  S. Bhattacharyya, "An Overview of Source-Specific Multicast
        (SSM)", RFC 3569,July 2003

Eiichi, et al.              Expires June 2007                   [Page 9]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006

[MBONE] Frequently Asked Questions (FAQ) on the Multicast Backbone
        (MBONE), ftp://venera.isi.edu/mbone/faq.txt

[2362]  D. Estrin,et.al, "Protocol Independent Multicast-Sparse Mode
        (PIM-SM): Protocol Specification.", RFC 2362, June 1998

[2858]  T. Bates, Y. Rekhter, R. Chandra, D. Katz.,"Multiprotocol Exten-
        sions for BGP-4", RFC 2858, June 2000

[RMT]   Reliable Multicast Transport Working Group web site,
        http://www.ietf.org/html.charters/rmt-charter.html, June 15,

[ESM]   Y.-H. Chu, S. G. Rao, and H. Zhang. A case for end system multi-
        cast. In Proceedings of ACM Sigmetrics, June 2000.

[YOID]  P. Francis. Yoid: Extending the Multicast Internet Architecture.
        White papar, http://www.aciri.org/yoid/.

[NICE]  S. Banerjee, C. Kommareddy, and B. Bhattacharjee. Scalable
        application layer multicast. In Proceedings of ACM SIGCOMM,Aug.

[ALMI]  D. Pendarakis, S. Shi, D. Verma, and M. Waldvogel. ALMI: An
        application level multicast infrastructure. In Proceedings of
        the 3rd USENIX Symposium on Internet Technologies and Sys-
        tems,Mar. 2001.

[TAG]   M. Kwon and S. Fahmy. Topology aware overlay networks forgroup
        communication. In Proceedings of NOSSDAV, May 2002

[DTO]   J. Liebeherr, M. Nahas, and W. Si. Application-layer multicast-
        ing with delaunay triangulation overlays. IEEE Journal on
        Selected Areas in Communications, 20(8):1472?1488, Oct. 2002.

[CAN]   S. Ratnasamy, M. Handley, R. Karp, and S. Shenker. Application-
        level multicast using content-addressable networks. In Proceed-
        ings of NGC, Nov. 2001.

        S. Q. Zhuang, B. Y. Zhao, A. D. Joseph, R. H. Katz, and J. D.
        Kubiatowicz. Bayeux: An architecture for scalable and fault-tol-
        erant wide-area data dissemination. In Proceedings of NOSS-
        DAV'01, June 2001

[SCX]   Y. Chawathe, S. McCanne, and E. A. Brewer. An Architecture for
        Internet Content Distributions as an Infrastructure Service,
        2000. Unpublished, http://www.cs.berkeley.edu/yatin/papers/.

Eiichi, et al.              Expires June 2007                  [Page 10]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006

        J. Jannotti, D. K. Gifford, K. L. Johnson, M. F. Kaashoek, and
        J. W. O. Jr. Overcast: Reliable multicasting with an overlay
        network. In Proceedings of USENIX Symposium on Operating Systems
        Design and Implementation, Oct. 2000.

[RMX]   Y. Chawathe, S. McCanne, and E. A. Brewer. RMX: Reliable multi-
        cast for heterogeneous networks. In Proceedings of IEEE INFOCOM,
        Mar. 2000.

[MSN]   S. Shi and J. S. Turner. Routing in overlay multicast networks.
        In Proceedings of IEEE INFOCOM, June 2002.

[OMNI]  S. Banerjee, C. Kommareddy, K. Kar, B. Bhattacharjee, and S.
        Khuller. Construction of an efficient overlay multicast infra-
        structure for real-time applications. In Proceedings of IEEE
        INFOCOM, Apr. 2003.

        Akamai Technologies, Inc. http://www.akamai.com.

[IBEAM] iBeam Broadcasting Corp. http://www.ibeam.com.

[XCID]  R. Boivie, N. Feldman , Y. Imai , W. Livens , D. Ooms, O. Pari-
        daens, "Explicit Multicast (Xcast) Basic Specification", draft-
        ooms-xcast-basic-spec-09.txt, December 2005.

[GIG]   A. De Simone, J. Tarr,"Defining the GIG Core", draft-gig-defin-
        ing-the-core-desimone-tarr-051030.pdf, October 2005.

[SAM]   "Scalable Adaptive Multicast Research Group" charter,
        http://www.irtf.org/charter?gtype=rg&group=samrg, June 2006.

[TAON]  Junghee Han, David Watson, and Farnam Jahanian, Topology Aware
        Overlay Networks, INFOCOM 2005

[SROU]  Lili Qiu, Yang Richard Yang, Yin Zhang, Scott Shenker, On Self-
        ish Routing in Internet-Like Environments, SIGCOMM 2003

[CMP]   Li Lao, Jun-Hong Cui, Mario Gerla, Dario Maggiorini,A Compara-
        tive Study of Multicast Protocols: Top, Bottom, or In theMid-
        dle?, UCLA, GI2005

[ITOL]  Zhi Li and Prasant Mohapatra,The Impact of Topology on Overlay
        Routing Service, SIGCOMM 2003

[PAA]   Zhu, W.; SunGuestEditor, M.-T.; ChenGuestEditor, L.-G.; Sikora,
        T,Proceedings of the IEEE Volume 93, Issue 1, Jan 2005

Eiichi, et al.              Expires June 2007                  [Page 11]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006

[EEA]   Wenjie Wang, Cheng Jin, Sugih Jamin, Network Overlay Construc-
        tion under Limited End-to-End Addressability,INFOCOM2005

        Mostafa H. Ammar, "Why Johnny Can't Multicast, Lessons about the
        Evolution of the Internet", 13th Intl. Workshop on Network and
        Operating Sys. Support for Digital Audio and Video (NOSSDAV

[NEMO]  "Network Mobility (nemo)",IETF working group charter,

[MANET] "Mobile Ad-hoc Networks (manet)" IETF working group charter,

[2434]  Narten, T., and Alvestrand, H., "Guidelines for Writing an IANA
        Considerations Section in RFCs", RFC 2434, October, 1998.

[2119]  Bradner, S., "Key words for use in RFCs to Indicate requirement
        Levels", BCP 14, RFC 2119, March 1997.

[3667]  S. Bradner,"IETF Rights in Contributions",RFC 3667, February

16. Authors Addresses

   Eiichi Muramoto
   WIDE project in Japan
   E-mail: muramoto@wide.ad.jp

   Yuji Imai
   WIDE project in Japan
   E-mail: ug@xcast.jp

   Nobuo Kawaguchi
   WIDE project in Japan
   E-mail: kawaguti@nagoya-u.jp

17. Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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

Eiichi, et al.              Expires June 2007                  [Page 12]

Internet Draftdraft-muramoto-irtf-sam-generic-require-01.txtNovember 2006


18. IPR Notices

   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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Eiichi, et al.              Expires June 2007                  [Page 13]

Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/