An Entity of Type: Network108434259, from Named Graph: http://dbpedia.org, within Data Space: dbpedia.org

RFC 2638 from the IETF defines the entity of the Bandwidth Broker (BB) in the framework of differentiated services (DiffServ). According to RFC 2638, a Bandwidth Broker is an agent that has some knowledge of an organization's priorities and policies and allocates quality of service (QoS) resources with respect to those policies. In order to achieve an end-to-end allocation of resources across separate domains, the Bandwidth Broker managing a domain will have to communicate with its adjacent peers, which allows end-to-end services to be constructed out of purely bilateral agreements. Admission control is one of the main tasks that a Bandwidth Broker has to perform, in order to decide whether an incoming resource reservation request will be accepted or not. Most Bandwidth Brokers use simple

Property Value
dbo:abstract
  • تُمثل وثيقة طلب التعليقات 2638 (RFC 2638) من اللجنة الخاصة لنظام الإنترنت (IETF) وسيط نقل البيانات في إطار شبكة الخدمات المميزة. وفقًا لوثيقة طلب التعليقات 2638، يعد وسيط نقل البيانات وسيطًا يملك بعض المعلومات عن أولويات المنظمة وسياساتها ويُحدد مصادر جودة الخدمة (QoS) المتعلقة بتلك السياسات. ولكي يتم تحديد المصادر بصورة شاملة من البداية للنهاية عبر المجالات المنفصلة، سيتعين على وسيط نقل البيانات التواصل مع أقران الإنترنت المجاورين، مما يتيح توصيل الخدمات الشاملة ببساطة من خلال الاتفاقيات الـثنائية. ويُعَد التحكم في الدخول واحدًا من المهام الأساسية التي يؤديها وسيط نقل البيانات، من أجل تحديد مدى قبول طلب حجز الموارد الجديد أو عدمه. تَستخدِم أغلب وسائط نقل البيانات نماذج بسيطة للتحكم في الدخول، بالرغم من أن هناك أيضًا مقترحات لأنظمة تَحكُّم في الدخول أكثر تعقيدًا وفقًا لمقاييسَ عدة، مثل: نسبة القبول، واستخدام الشبكة، إلخ. ويعمل وسيط نقل البيانات بصفته نقطة تحديد السياسات (PDP) لتحديد ما إذا كان سيتم السماح بتدفق المرور أم رفضها، بينما تعمل المُسيّرات الطرفية بصفتها نقاط تنفيذ السياسات (PEPs) للتحكم في المرور (السماح للحِزَم المميزة، أو إسقاطها ببساطة). تسمح الشبكات المميزة بوجود خدمتين للإرسال بعيدًا عن الإرسال الافتراضي؛ وهما: خدمة شبكة جهد أفضل الإرسال الثابت (AF) والإرسال العاجل يقدم الإرسال الثابت خدمة تفوق خدمة جهد أفضل للمرور، ولكنه يماثل مرور شبكة جهد أفضل من حيث توقع حدوث الاندفاعات وتغير وقت الحزمة (PDV). ويتم إعطاء حزم الإرسال الثابت الموجودة خارج الملف أولوية أقل عن طريق تمييزها كالشبكة ذات أفضل جهد للمرور. أما الإرسال العاجل فيقدم خدمة السلك الافتراضي مع تشكيل حركة المرور لمنع اندفاع البيانات، والتحكم في الدخول بشكلٍ صارم (يتم إسقاط الحزم الخارجة عن الملف) وصفّ منفصل لمرور الإرسال العاجل في قلب المُسيّرات، والتي تحافظ على بقاء الصفوف صغيرة وتتجنب الحاجة إلى التحكم في العازل. وتكون خدمة الإرسال العاجل المقدمة قليلة الفقد، كما يستغرق وقت فترة أقل، ويكون تغير وقت الحزمة (PDV) أقل. ومن ثَم، وبالرغم من أن وسيط نقل البيانات يقوم بتحديد معدل نقل البيانات، فإنه في الحقيقة يحدد خدمات النقل (مثل: مصادر جودة الخدمة (QoS)). يمكن إعداد وسائط نقل البيانات عن طريق سياسات تنظيمية، وتتبع التحديد الحالي للمرور المحدد، واستيعاب الطلبات الجديدة لتحديد المرور في ضوء السياسات والتحديد الحالي. وتحتاج وسائط نقل البيانات فقط لتكوين علاقات محدودة الثقة مع قرانات الإنترنت الخاصة بها في المجالات المجاورة، على عكس الخطط التي تتطلب ضبط تحديدات التدفق في المُسيّرات عبر مسار شامل من البداية إلى النهاية. من الناحية التقنية العملية، تتيح هندسة وسيط نقل البيانات إبقاء الحالة على أساس المجال الإداري، بدلاً من على كل مسيّر، كما تتيح هندسة شبكة الخدمات المميزة الاقتصار وفقًا لحالة التدفق أو المسيّرات. لقد اتسع نطاق وسائط نقل البيانات ولم تعد مقصورةً على مجالات شبكة الخدمات المميزة فقط. وما دام يمكن توجيه آلية جودة الخدمة التحتية وفقًا لنظام شبكة الخدمات المميزة، يمكن لوسيط نقل البيانات فهمها والتواصل مع قرانات الإنترنت المجاورة لها، أي أنه يجب أن تكون 'لغة التواصل المشترك' لجودة الخدمة في الـإنترنت عبر شبكة الخدمات المميزة. ربما يكون هناك أكثر من وسيط واحد لنقل البيانات في مجالٍ ما، مع أنه في حالة وجود أكثر من واحد، تضع وثيقة طلب التعليقات 2638 تصورًا يوضح أن وسيطًا واحدًا فقط لنقل البيانات سوف يؤدي وظيفته بصفته الوسيط لمجال المستوى الأعلى. * يتحكم في مصادر كل سحابة (وسيط نقل البيانات) * تكون الحزم «ملونة» للإشارة إلى «وضع» الإرسال * يركز على المجموعات وليس على التدفق الفردي * يتم الضبط على محيط الشبكة للحصول على الخدمات * يُستخدم مع تبديل متعدد البروتوكولات باستخدام المؤشرات التعريفية (MPLS) وهندسة المرور (TE) * ضمانات «إجمالية» فقط لجودة الخدمة! * يعتبر ضعيف المستوى بالنسبة للضمانات التي تُقدم للتطبيقات الشاملة (ar)
  • RFC 2638 from the IETF defines the entity of the Bandwidth Broker (BB) in the framework of differentiated services (DiffServ). According to RFC 2638, a Bandwidth Broker is an agent that has some knowledge of an organization's priorities and policies and allocates quality of service (QoS) resources with respect to those policies. In order to achieve an end-to-end allocation of resources across separate domains, the Bandwidth Broker managing a domain will have to communicate with its adjacent peers, which allows end-to-end services to be constructed out of purely bilateral agreements. Admission control is one of the main tasks that a Bandwidth Broker has to perform, in order to decide whether an incoming resource reservation request will be accepted or not. Most Bandwidth Brokers use simple admission control modules, although there are also proposals for more sophisticated admission control according to several metrics such as acceptance rate, network utilization, etc. The BB acts as a Policy Decision Point (PDP) in deciding whether to allow or reject a flow, whilst the edge routers acts as Policy Enforcement Points (PEPs) to police traffic (allowing and marking packets, or simply dropping them). DiffServ allows two carrier services apart from the default best-effort service: Assured Forwarding (AF) and Expedited Forwarding (EF). AF provides a better-than-best-effort service, but is similar to best-effort traffic in that bursts and packet delay variation (PDV) are to be expected. Out of profile AF packets are given a lower priority by being marked as best effort traffic. EF provides a virtual wire service with traffic shaping to prevent bursts, strict admission control (out of profile packets are dropped) and a separate queue for EF traffic in the core routers, which together keep queues small and avoid the need for buffer management. The resulting EF service is low loss, low delay and low PDV. Hence although loosely a BB allocates bandwidth, really it allocates carrier services (i.e. QoS resources). Bandwidth Brokers can be configured with organizational policies, keep track of the current allocation of marked traffic, and interpret new requests to mark traffic in light of the policies and current allocation. Bandwidth Brokers only need to establish relationships of limited trust with their peers in adjacent domains, unlike schemes that require the setting of flow specifications in routers throughout an end-to-end path. In practical technical terms, the Bandwidth Broker architecture makes it possible to keep state on an administrative domain basis, rather than at every router, and the DiffServ architecture makes it possible to confine per flow state to just the edge or leaf routers. The scope of BBs has expanded and they are now not restricted to DiffServ domains. As long as the underlying QoS mechanism can be mapped to DiffServ behaviour, then a BB can understand it and communicate with its adjacent peers, i.e. the 'lingua franca' of QoS in the Internet should be DiffServ. There may be more than one BB in a domain, though if there are, RFC 2638 envisages that only one BB will function as the top-level inter-domain BB. * Manages each cloud’s resources (Bandwidth Broker) * Packets are "coloured" to indicate forwarding "behavior" * Focus on aggregates and NOT on individual flows * Policing at network periphery to get services * Used together with Multiprotocol Label Switching (MPLS) and Traffic Engineering (TE) * "Aggregated" QoS guarantees only! * Poor on the guarantees for end-to-end applications (en)
dbo:wikiPageExternalLink
dbo:wikiPageID
  • 2783840 (xsd:integer)
dbo:wikiPageLength
  • 5397 (xsd:nonNegativeInteger)
dbo:wikiPageRevisionID
  • 1079007157 (xsd:integer)
dbo:wikiPageWikiLink
dbp:wikiPageUsesTemplate
dcterms:subject
rdf:type
rdfs:comment
  • تُمثل وثيقة طلب التعليقات 2638 (RFC 2638) من اللجنة الخاصة لنظام الإنترنت (IETF) وسيط نقل البيانات في إطار شبكة الخدمات المميزة. وفقًا لوثيقة طلب التعليقات 2638، يعد وسيط نقل البيانات وسيطًا يملك بعض المعلومات عن أولويات المنظمة وسياساتها ويُحدد مصادر جودة الخدمة (QoS) المتعلقة بتلك السياسات. ولكي يتم تحديد المصادر بصورة شاملة من البداية للنهاية عبر المجالات المنفصلة، سيتعين على وسيط نقل البيانات التواصل مع أقران الإنترنت المجاورين، مما يتيح توصيل الخدمات الشاملة ببساطة من خلال الاتفاقيات الـثنائية. ويُعَد التحكم في الدخول واحدًا من المهام الأساسية التي يؤديها وسيط نقل البيانات، من أجل تحديد مدى قبول طلب حجز الموارد الجديد أو عدمه. تَستخدِم أغلب وسائط نقل البيانات نماذج بسيطة للتحكم في الدخول، بالرغم من أن هناك أيضًا مقترحات لأنظمة تَحكُّم في الدخول أكثر تعقيدًا وفقًا لمقاييسَ عدة، مثل: نس (ar)
  • RFC 2638 from the IETF defines the entity of the Bandwidth Broker (BB) in the framework of differentiated services (DiffServ). According to RFC 2638, a Bandwidth Broker is an agent that has some knowledge of an organization's priorities and policies and allocates quality of service (QoS) resources with respect to those policies. In order to achieve an end-to-end allocation of resources across separate domains, the Bandwidth Broker managing a domain will have to communicate with its adjacent peers, which allows end-to-end services to be constructed out of purely bilateral agreements. Admission control is one of the main tasks that a Bandwidth Broker has to perform, in order to decide whether an incoming resource reservation request will be accepted or not. Most Bandwidth Brokers use simple (en)
rdfs:label
  • وسيط نقل البيانات (ar)
  • Bandwidth Broker (en)
owl:sameAs
prov:wasDerivedFrom
foaf:isPrimaryTopicOf
is dbo:wikiPageWikiLink of
is foaf:primaryTopic of
Powered by OpenLink Virtuoso    This material is Open Knowledge     W3C Semantic Web Technology     This material is Open Knowledge    Valid XHTML + RDFa
This content was extracted from Wikipedia and is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License