מאמר זה מספק סקירה קצרה של הדרישות לדיוק ועקיבות זמן (שעון) לפי MiFID II, מידע כללי על פרוטוקול PTP (פרוטוקול לסנכרון שעונים ברשתות תקשורת – Time Precision Protocol) ומה תפקידו במילוי דרישות אלו, שיקולים להוכחה כי הציוד ברשת מתאים למטרה, כמו כן הדגמה והוכחה כי הרשתות ממלאות אחר MiFID II לפי RTS 25.
RTS 25 – רמות דיוק לשעונים ברשתות עסקיות
לפני ובהתאם לכניסת MiFID II לתוקף, חובה על חברות המסחר לוודא כי יש להם את האישורים והסמכות הנדרשות לבצע את הפעילויות הרגולטוריות הרלוונטיות. דיוק שעונים עסקיים – כמפורט ב-RTS 25 – הינו חלק חיוני למטרות אלו, כגון דיווח על נתוני שקיפות לאחר המסחר. שילוב טכנולוגיות ישמש על מנת להשיג מטרה זו, אך הדרישה לחותמת זמן עקבית ביישומים בחברת המסחר פירושה כי סנכרון ברשתות IP באמצעות PTP (פרוטוקול זמן מדויק המוגדר ב-IEEE1588-2008) יהיה בעל תפקיד מרכזי.
בפרט, על הצורך בשעון מדויק בעת דיווח על תהליכי ותוצאות המסחר, הובהר כי אותם מקורות תזמון עצמיים ובין חברות המסחר חייבים להיות בעלי דיוק (סטייה מקסימלית מזמן יחסי) ואחידות עם זמן יחסי, על מנת להבטיח כי הרשויות יוכלו לקבוע כראוי את ציר הזמן של אירועים ברי דיווח.
רמות הדיוק והסטייה המקסימלית מהזמן האוניברסלי המתואם (UTC) המפורט עבור שעונים עסקיים תלויים בהשעיה בין נתב – לנתב של מערכות המסחר (במקרה של מפעילי מסחר) או סוגי פעילויות המסחר (במקרה של משתתפים במסחר). הדרישות הנובעות מכך מודגמות להלן.
תזמון MIFID II/ESMA RTS 25 רמות דיוק לשעונים עסקיים
כפי שנראה, רמות דיוק גבוהות כ- 1μs, עם סטייה של לא יותר מ- 100μs מ- UTC, עשויות להידרש עבור תאימות לרגולציה.
המשימה המשותפת של ספקי ציוד וחברות מסחר היא לקבוע:
- כיצד לספק תזמון באופן מדויק אל ובקרב חברות המסחר.
- כיצד להוכיח את עקיבות הזמן, הנדרשת לתאימות רגולטורית, לפחות פעם בשנה (לפי RTS 25 סעיף 4)
‘ESMA RTS 25: תקנים טכניים רגולטורים בנושא סנכרון שעון’ מספקים הנחיות נוספות לגבי הדרישות לדיוק ועקביות התזמון הנדרשות לשם תאימות עם MiFID II.
מבוא ל- PTP
GPS משמש בדרך כלל לסנכרון זמן ברשתות תקשורת ברחבי העולם. עם זאת, התקנות GPS זקוקות לאנטנות חיצוניות עם קליטה תקינה של לוויינים (שלעיתים קרובות קשה להשיג בסביבות עירוניות) וסובלים מחוסר אבטחה “מסורתי” (רגישות לשיבושים ולזיופים). הסתמכות מוחלטת על GPS להעברת זמן/שעון מדויק ממקום למקום מהווה סיכון חד משמעי.
לעומת זאת, כחלופה מעולה – PTP הינו שיטת העברת שעון מדויקת ביותר. בנוסף, במוסדות מסחר, גופים פיננסים ויישומים אחרים כגון טלקום, שירותים ציבוריים ושידורים שונים, סנכרון אמין דרך רשתות אתרנט (Ethernet) אשר כבר משמשות למידע חיוני ליישומים קיימים ומגוונים – יש יתרונות רבים.
מהו PTP?
PTP הינו פרוטוקול העברת זמן (שעון) מבוסס הודעות (Message Based), המשמש להעברת זמן (פאזה) ו/או תדר (Frequency) ברשתות (IP (Packet-based. הפרוטוקול מוודא כי נקודות שונות ברשת מסונכרנות באופן מדויק לשעון היחסי (הראשי) כך שהרשת עומדת במגבלות הביצועים הספציפיות בהתאם לדרישות היישומים ברשת.
הודעות התזמון של PTP מועברות בנתונים של חבילות המידע ברשת התקשורת, כלומר נמצאת ב-PAYLOAD של חבילת המידע (Packet).
הזמן המדויק שחבילת מידע עוברת בנקודת כניסה או יציאה של התקן תומך ב- PTP נרשם באמצעות חותמת זמן (Timestamp). מכיוון שלחבילות המידע לוקח אורכי זמן שונים לעבור ברשת – מסיבות שונות כגון תורים במתגים ובנתבים בדרך – זה מוביל לשינוי בעיכוב/השעיה של חבילה .
כדי להפחית את השפעת ה-PDV, ניתן להשתמש בשעוני גבול או בשעוני מעבר (TCs – Transparent Clocks) על מנת לעמוד ביעדי הדיוק של הרשת.
הערכת שגיאת שעון הנגרמת על ידי התקנים אלו (BC ,TC..) הינה חיונית לקביעת טופולוגית הרשת, התאמת הציוד והצגת תאימות וסנכרון הרשת.
שעוני BC מכיילים את עצמם על ידי החזרה וחידוש תזמון PTP מהשעון הקודם בשרשרת ובכך ממזערים את הצטברות PDV בשעון היעד.
אם נעשה שימוש בשעוני TC, ה-PDV נכתב על ידי כל TC בתוך שדה תיקון בחבילת המידע. אז לשעון היעד יש רישום של עיכוב לכל TC בנתיב.
איך עובד PTP?
PTP משמש להחלפת הודעות תזמון על מנת להעביר את הזמן מהשעון הראשי (MASTER) למספר שעוני יעד משניים . ההודעות התזמון הן SYNC, FOLLOW_UP ,DELAY_REQ ו-DELAY_RESP כמוצג להלן.
הודעות אלו מניבות ארבע חותמות זמן (t1, t2, t3 ו- t4), מהן ניתן לחשב את זמן המעבר הלוך ושוב של ההודעות משעון ראשי ליעד וחזרה לראשי (בהנחה ששעון משני מתקדם בקצב זהה לשעון הראשי).
אז מוערך קיזוז הזמן תוך שימוש בהנחה כי השעיית רשת חד כיוונית הינה חצי מהשעיה הכוללת (Round Trip Delay) ומשמש לתיקון בסיס זמן שעון משני (SLAVE) על מנת להתאים את השעון הראשי (MASTER). יש לשים לב כי על הנחת אסימטריה (ASSYMETRY), כלומר הנתיבים קדימה ואחורה הם באורך שווה. במידה והם באורכים שונים, מה שבדרך כלל נגרם על ידי תורים במתגים ובנתבים, זה יוביל לשגיאה בהערכת קיזוז הזמן, וזו משמעותה של אסימטריה.
קביעת ואימות ביצועי PTP
מה הם הביצועים הדרושים של הרשת והציוד?
כפי שצוין קודם, TRS-25 מאפשר סטייה מקסימלית של ±1μs באות הזמן בין שעון הראשי לבין קצה היישום.
התרשים להלן מספק דוגמה לאופן בו ניתן לפרק את המפרט לתת-סעיפים על מנת לספק מפרטי ציוד לשעונים ראשיים (Grand Master), מתגי/נתבי רשת מותאמים ל- PTP (שעוני גבול BC או שקופים/מעבר TC) ופונקציונליות של שעונים משניים (SLAVE) בשרת היעד (סביר להניח כי שעון ייושם בכרטיס רשת – NIC).
בהתאם למספר קפיצות הרשת בין נקודות הסיום של הרשת, גבולות ביצועי שעוני BC ו- TC עשויים להשתנות לפי היישום והפריסה. מבחינת התרשים, 5 קפיצות יתנו גבול של ±600ns / 5 = 120ns לכל התקן.
תאימות הדדית (INTEROPERABILITY) של פרוטוקול PTP
למרות שלעיתים קרובות מתעלמים ממנו, פרט מרכזי בפריסת רשתות PTP יציבות הוא לוודא כי כל ההתקנים מיישמים את אותו פרופיל PTP מבחינת התקן והגרסה.
לצורך כך ההערכה הראשונית אמורה לכלול אימות של שדות הודעות PTP, מה שמונע איבוד זמן בשל תצורה שגויה ומזהה בעיות תאימות הדדית בקנה מידה גדול.
האם ההתקנים מתאימים למטרה?
כפי שתואר קודם, יש תחילה להבין את דרישות הדיוק (ACCURACY) והעקיבות (TRACEABILITY) ליישום ספציפי ולאחר מכן להבין את טופולוגית פריסת הרשת, אז ניתן לקבוע את דרישות הביצועים להתקנים אינדיווידואליים – הן עבור מפעילי המסחר שמעריכים את הציוד לפני היישום והן עבור יצרני הציוד המספקים הוכחת יכולת.
על מנת להוכיח את ביצועי PTP של ציוד הרשת:
- יש להראות כי הציוד יכול להתחבר ולהשתלב נכון לסביבה תומכת PTP. מומלץ להשתמש בציוד בדיקה היכול ליצור ולשלוט בחילופי הודעות PTP על מנת למנוע, לדוגמה, ‘מיסוך’ בעיות תאימות הדדית (בעיה נפוצה בעת שימוש בציוד רשת מסחרי למטרות בדיקה).
- יש למדוד את דיוק תזמון ‘במצב יציב’ (STEADY STATE) ישירות בהודעות PTP או באמצעות חיבור תזמון/שעון חיצוני, אם קיים. הכרחי כי ציוד הבדיקה המאמת ביצועים יהיה בעל דיוק מדידה בסדר גודל טוב יותר מאשר מפרט ביצועי ההתקן (הערה: זה צריך לכסות על כל התקנת המדידה, שעליה להיות מותאמת/מסונכרנת בזמן על מנת לאשר, לדוגמה, עקיבות זמן (TRACEABILITY).
- יש לבדוק ולמדוד גם את התגובה לתנאים שליליים (CONDITIONS NEGATIVE) אפשריים (שגיאות פרוטוקול, קיזוזי זמן וכו’), כלומר ‘הביצוע הגרוע ביותר’. יש ליישם קיזוזי תזמון הדרגתיים ארוכי טווח וקפיצות תזמון קצרות טווח על מנת לבדוק את עמידות ושרידות/חוסן הציוד.
שוב, זה צריך להתאפשר ללא השפעה על מדידות דיוק תזמון בו זמנית.
כיצד באפשרותי לאמת ולהדגים את ביצועי הרשת?
ניתן למדוד גם את שגיאת הזמן (ERROR TIME) של PTP ואת השעון המשוחזר (RECOVERED CLOCK) בנקודות שונות ברשת על מנת להבטיח את הביצוע לפני, במהלך ואחרי הפריסה, מה שמאפשר למפעילי מקומות מסחר (TRADE) להוכיח תאימות מתמשכת ל- MiFID II כמפורט ב- RTS 25.
בדיקת רשת, בדיקת מדגם ו’דוחות עצמיים’ של התקן, כולן גישות שימושיות פוטנציאליות בהתאם לצרכי הארגון.
